@TECHREPORT{rfc31,
AUTHOR="D. Bobrow and William R. Sutherland",
TITLE="Binary Message Forms in Computer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=31,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1968,
ABSTRACT="Suggest alternative approaches and methods for describing
messages.",
URL="http://www.rfc-editor.org/rfc/rfc31.txt"
}

@TECHREPORT{rfc1,
AUTHOR="S. D. Crocker",
TITLE="Host Software",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=1969,
ABSTRACT="Discusses the Host software and initial experiments on the
ARPA Network.",
URL="http://www.rfc-editor.org/rfc/rfc1.txt"
}

@TECHREPORT{rfc11,
AUTHOR="G. Deloche",
TITLE="Implementation of the {Host-Host} software procedures in {GORDO}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=11,
DAYS=15,
MONTH=aug,
YEAR=1969,
ABSTRACT="Discussion of Host-Host Procedures and GORDO as a time-sharing
system that was implemented on a SDS Sigma 7."
}

@TECHREPORT{rfc12,
AUTHOR="M. Wingfield",
TITLE="{IMP-Host} interface flow diagrams",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=12,
PAGES=1,
DAYS=15,
MONTH=aug,
YEAR=1969,
ABSTRACT="Flow Diagrams Flow diagrams that indicate the logical sequence
of hardware operations which occur within the IMP-HOST interface.",
URL="http://www.rfc-editor.org/rfc/rfc12.txt"
}

@TECHREPORT{rfc13,
AUTHOR="V. G. Cerf",
TITLE="Zero Text Length {EOF} Message",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=13,
PAGES=1,
DAYS=15,
MONTH=aug,
YEAR=1969,
ABSTRACT="Proposes a zero text length EOF (End-Of-File) message.",
URL="http://www.rfc-editor.org/rfc/rfc13.txt"
}

@TECHREPORT{rfc15,
AUTHOR="C. S. Carr",
TITLE="Network subsystem for time sharing hosts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=15,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=1969,
ABSTRACT={Proposes a subsystem called {"}Telnet{"}, which would be a shell
program around the network system primitives, allowing a teletype or
similar terminal at a remote host to function as a teletype at the
serving host.},
URL="http://www.rfc-editor.org/rfc/rfc15.txt"
}

@TECHREPORT{rfc16,
AUTHOR="S. D. Crocker",
TITLE="{M.I.T}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=16,
PAGES=1,
DAYS=15,
MONTH=aug,
YEAR=1969,
ABSTRACT="Announcement that MIT is now to receive all Network Working
Group memos.",
URL="http://www.rfc-editor.org/rfc/rfc16.txt"
}

@TECHREPORT{rfc17,
AUTHOR="J. E. Kreznar",
TITLE="Some questions re: {Host-IMP} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=17,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1969,
ABSTRACT="Queries and opinions regarding the HOST-IMP Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc17.txt"
}

@TECHREPORT{rfc18,
AUTHOR="V. G. Cerf",
TITLE="{IMP-IMP} and {HOST-HOST} Control Links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=18,
PAGES=1,
DAYS=15,
MONTH=sep,
YEAR=1969,
ABSTRACT="Suggestions regarding the Host-Host control link. 017a
Comments in response to Kreznar's questions which were raised in RFC 17.",
URL="http://www.rfc-editor.org/rfc/rfc18.txt"
}

@TECHREPORT{rfc19,
AUTHOR="J. E. Kreznar",
TITLE="Two protocol suggestions to reduce congestion at swap bound nodes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=19,
PAGES=2,
DAYS=15,
MONTH=oct,
YEAR=1969,
ABSTRACT="Suggests alternatives in reducing congestion at swap-bound
nodes.",
URL="http://www.rfc-editor.org/rfc/rfc19.txt"
}

@TECHREPORT{rfc20,
AUTHOR="V. G. Cerf",
TITLE="{ASCII} format for network interchange",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=20,
PAGES=9,
DAYS=15,
MONTH=oct,
YEAR=1969,
ABSTRACT="Discusses the use of standard 7-bit ASCII embedded in an 8-bit
byte whose high order bit is always 1.",
URL="http://www.rfc-editor.org/rfc/rfc20.txt"
}

@TECHREPORT{rfc21,
AUTHOR="V. G. Cerf",
TITLE="Network meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=21,
DAYS=15,
MONTH=oct,
YEAR=1969,
ABSTRACT="Attendance list and topics discussed.",
URL="http://www.rfc-editor.org/rfc/rfc21.txt"
}

@TECHREPORT{rfc22,
AUTHOR="V. G. Cerf",
TITLE="Host-host control message formats",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=22,
PAGES=2,
DAYS=15,
MONTH=oct,
YEAR=1969,
ABSTRACT="Reports on a new control message format which does not use the
7-bit ASCII character mode of transmission.",
URL="http://www.rfc-editor.org/rfc/rfc22.txt"
}

@TECHREPORT{rfc23,
AUTHOR="G. Gregg",
TITLE="Transmission of Multiple Control Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=23,
DAYS=15,
MONTH=oct,
YEAR=1969,
ABSTRACT="Discusses how a network program at a site should be prepared
to send or receive more than one control message in a single control
communication.",
URL="http://www.rfc-editor.org/rfc/rfc23.txt"
}

@TECHREPORT{rfc25,
AUTHOR="S. D. Crocker",
TITLE="No High Link Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=25,
DAYS=15,
MONTH=oct,
YEAR=1969,
ABSTRACT="Suggests that no link number over 63 be used.",
URL="http://www.rfc-editor.org/rfc/rfc25.txt"
}

@TECHREPORT{rfc3,
AUTHOR="S. D. Crocker",
TITLE="Documentation conventions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3,
DAYS=15,
MONTH=apr,
YEAR=1969,
ABSTRACT="Establishes a definition of style, content, form, and
distribution of the Network Working Group's notes (Obsoleted by RFC 10).",
URL="http://www.rfc-editor.org/rfc/rfc3.txt"
}

@TECHREPORT{rfc4,
AUTHOR="Ehud Shapiro",
TITLE="Network timetable",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1969,
ABSTRACT="Discusses installation, configuration, network checkout, and
test messages run between SRI and UCLA.",
URL="http://www.rfc-editor.org/rfc/rfc4.txt"
}

@TECHREPORT{rfc5,
AUTHOR="J. Rulifson",
TITLE="Decode Encode Language {(DEL)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5,
DAYS=15,
MONTH=jun,
YEAR=1969,
ABSTRACT="Details the machine independent language DEL (Decode-Encode
Language).",
URL="http://www.rfc-editor.org/rfc/rfc5.txt"
}

@TECHREPORT{rfc6,
AUTHOR="S. D. Crocker",
TITLE="Conversation with Bob Kahn",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6,
DAYS=15,
MONTH=apr,
YEAR=1969,
ABSTRACT="Conversations regarding code conversion in the IMP's, IMP-HOST
communication, and HOST software.",
URL="http://www.rfc-editor.org/rfc/rfc6.txt"
}

@TECHREPORT{rfc7,
AUTHOR="G. Deloche",
TITLE="{Host-IMP} interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=1969,
ABSTRACT="Discusses Host-IMP interface issues.",
URL="http://www.rfc-editor.org/rfc/rfc7.txt"
}

@TECHREPORT{rfc8,
AUTHOR="G. Deloche",
TITLE="Functional specifications for the {ARPA} Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=8,
DAYS=15,
MONTH=may,
YEAR=1969,
ABSTRACT="Discusses transmission features, functional software
specifications, and the Link establishment procedure."
}

@TECHREPORT{rfc28,
AUTHOR="W. K. English",
TITLE="Time Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=28,
DAYS=15,
MONTH=jan,
YEAR=1970,
ABSTRACT="Request for comments relative to Network time standards.",
URL="http://www.rfc-editor.org/rfc/rfc28.txt"
}

@TECHREPORT{rfc29,
AUTHOR="R. E. Kahn",
TITLE="Response to {RFC} 28",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=29,
DAYS=15,
MONTH=jan,
YEAR=1970,
ABSTRACT="Comments in response to English's question which was raised in
RFC 28.",
URL="http://www.rfc-editor.org/rfc/rfc29.txt"
}

@TECHREPORT{rfc30,
AUTHOR="S. D. Crocker",
TITLE="Documentation Conventions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=30,
DAYS=15,
MONTH=feb,
YEAR=1970,
ABSTRACT="Revises the definition of style, content, form, and
distribution of the Network Working Group's notes. Replaces RFCs
10,16,24,27.",
URL="http://www.rfc-editor.org/rfc/rfc30.txt"
}

@TECHREPORT{rfc32,
AUTHOR="J. B. Cole",
TITLE="Some Thoughts on {SRI's} Proposed Real Time Clock",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=32,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1970,
ABSTRACT="References and comments on RFCs 28,29.",
URL="http://www.rfc-editor.org/rfc/rfc32.txt"
}

@TECHREPORT{rfc33,
AUTHOR="S. D. Crocker",
TITLE="New {Host-Host} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=33,
PAGES=19,
DAYS=15,
MONTH=feb,
YEAR=1970,
ABSTRACT="Revises RFC 11, and indicates numerous changes in the old
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc33.txt"
}

@TECHREPORT{rfc34,
AUTHOR="W. K. English",
TITLE="Some Brief Preliminary Notes on the Augmentation Research Center Clock",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=34,
PAGES=2,
DAYS=15,
MONTH=feb,
YEAR=1970,
ABSTRACT="Describes the ARC Clock system.",
URL="http://www.rfc-editor.org/rfc/rfc34.txt"
}

@TECHREPORT{rfc35,
AUTHOR="S. D. Crocker",
TITLE="Network Meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=35,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1970,
ABSTRACT="Announcement of a network meeting: date, time, place, and
proposed agenda.",
URL="http://www.rfc-editor.org/rfc/rfc35.txt"
}

@TECHREPORT{rfc36,
AUTHOR="S. D. Crocker",
TITLE="Protocol Notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=36,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1970,
ABSTRACT="A three part overview of the Network Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc36.txt"
}

@TECHREPORT{rfc37,
AUTHOR="S. D. Crocker",
TITLE="Network Meeting Epilogue, etc",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=37,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1970,
ABSTRACT="Network Meeting notes from 17 March 1970.",
URL="http://www.rfc-editor.org/rfc/rfc37.txt"
}

@TECHREPORT{rfc38,
AUTHOR="S. M. Wolfe",
TITLE="Comments on Network Protocol from {NWG/RFC} {#36}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=38,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1970,
ABSTRACT="Continued discussion on the proposed Network Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc38.txt"
}

@TECHREPORT{rfc39,
AUTHOR="E. Harslem and John F. Heafner",
TITLE="Comments on Protocol Re: {NWG/RFC} {#36}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=39,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1970,
ABSTRACT="More suggestions to be considered as additions to RFC 36 -
Network Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc39.txt"
}

@TECHREPORT{rfc40,
AUTHOR="E. Harslem and John F. Heafner",
TITLE="More Comments on the Forthcoming Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=40,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1970,
ABSTRACT="Further elaborations on the errors, queries, and Host status
that were mentioned in RFC 39.",
URL="http://www.rfc-editor.org/rfc/rfc40.txt"
}

@TECHREPORT{rfc41,
AUTHOR="J. T. Melvin",
TITLE="{IMP-IMP} Teletype Communication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=41,
DAYS=15,
MONTH=mar,
YEAR=1970,
ABSTRACT="Comments that transmitting IMP sites should use 24 hour time
and include the time zone designation.",
URL="http://www.rfc-editor.org/rfc/rfc41.txt"
}

@TECHREPORT{rfc42,
AUTHOR="E. Ancona",
TITLE="Message Data Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=42,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1970,
ABSTRACT="A proposal that the first eight bits of a normal message be
reserved for a message data type.",
URL="http://www.rfc-editor.org/rfc/rfc42.txt"
}

@TECHREPORT{rfc43,
AUTHOR="A. G. Nemeth",
TITLE="Proposed Meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=43,
DAYS=15,
MONTH=apr,
YEAR=1970,
ABSTRACT="An announcement of a meeting to discuss the Local Interaction
Language system.",
URL="http://www.rfc-editor.org/rfc/rfc43.txt"
}

@TECHREPORT{rfc44,
AUTHOR="A. Shoshani and R. Long and A. Landsberg",
TITLE="Comments on {NWG/RFC} 33 and 36",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=44,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1970,
ABSTRACT="General discussion and suggestions for refinements to the
HOST-HOST Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc44.txt"
}

@TECHREPORT{rfc45,
AUTHOR="J. B. Postel and S. D. Crocker",
TITLE="New Protocol is Coming",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=45,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1970,
ABSTRACT="Announcement of a new version of the Network Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc45.txt"
}

@TECHREPORT{rfc46,
AUTHOR="E. Meyer",
TITLE="{ARPA} Network protocol notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=46,
PAGES=17,
DAYS=15,
MONTH=apr,
YEAR=1970,
ABSTRACT="Comments and suggestions from the NWG at Project MAC, based
upon the protocol outlined in RFCs 33,36.",
URL="http://www.rfc-editor.org/rfc/rfc46.txt"
}

@TECHREPORT{rfc47,
AUTHOR="J. B. Postel and S. D. Crocker",
TITLE="{BBN's} Comments on {NWG/RFC} {#33}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=47,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1970,
ABSTRACT="Comments from BBN regarding RFC 33 (New HOST-HOST Protocol).",
URL="http://www.rfc-editor.org/rfc/rfc47.txt"
}

@TECHREPORT{rfc48,
AUTHOR="J. B. Postel and S. D. Crocker",
TITLE="Possible protocol plateau",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=48,
PAGES=18,
DAYS=15,
MONTH=apr,
YEAR=1970,
ABSTRACT="Reporting activities since the Network meeting of 17 March
1970.",
URL="http://www.rfc-editor.org/rfc/rfc48.txt"
}

@TECHREPORT{rfc49,
AUTHOR="Edwin W. Meyer",
TITLE="Conversations with {S.} Crocker {(UCLA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=49,
MONTH=apr,
YEAR=1970,
ABSTRACT="Discussion of telephone conversations relating to the Network
Protocol, specifically regarding Meyer's proposal in RFC 46.",
URL="http://www.rfc-editor.org/rfc/rfc49.txt"
}

@TECHREPORT{rfc50,
AUTHOR="E. Harslen and J. Heafner",
TITLE="Comments on the Meyer Proposal",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=50,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1970,
ABSTRACT="General acceptance on RFC 46, plus comments on the seven
issues raised in RFC 47.",
URL="http://www.rfc-editor.org/rfc/rfc50.txt"
}

@TECHREPORT{rfc51,
AUTHOR="M. Elie",
TITLE="Proposal for a Network Interchange Language",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=51,
DAYS=15,
MONTH=may,
YEAR=1970,
ABSTRACT="A proposal to specify a high level programming language for
computer networks, specifically the ARPA network."
}

@TECHREPORT{rfc52,
AUTHOR="J. B. Postel and S. D. Crocker",
TITLE="Updated distribution list",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=52,
PAGES=3,
DAYS=15,
MONTH=jul,
YEAR=1970,
ABSTRACT="Mailing list for distributing the RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc52.txt"
}

@TECHREPORT{rfc53,
AUTHOR="S. D. Crocker",
TITLE="Official protocol mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=53,
PAGES=1,
DAYS=15,
MONTH=jun,
YEAR=1970,
ABSTRACT="Group discussion on rules for establishing and modifying an
official Host-Host protocol.",
URL="http://www.rfc-editor.org/rfc/rfc53.txt"
}

@TECHREPORT{rfc54,
AUTHOR="S. D. Crocker and J. B. Postel and J. Newkirk and M. F. Kraley",
TITLE="Official Protocol Proffering",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=54,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1970,
ABSTRACT="Submission of the Official Protocol for comments and
suggestions.",
URL="http://www.rfc-editor.org/rfc/rfc54.txt"
}

@TECHREPORT{rfc55,
AUTHOR="J. Newkirk and M. F. Kraley and J. B. Postel and S. D. Crocker",
TITLE="Prototypical implementation of the {NCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=55,
PAGES=23,
DAYS=15,
MONTH=jun,
YEAR=1970,
ABSTRACT="A prototypical specification in a prose format of what the NCP
could look like.",
URL="http://www.rfc-editor.org/rfc/rfc55.txt"
}

@TECHREPORT{rfc56,
AUTHOR="E. Belove and D. L. Black and R. Flegal and L. G. Farquar",
TITLE="Third Level Protocol: Logger Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=56,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1970,
ABSTRACT="All explanations in this RFC are meant to describe functional
characteristics rather than design.",
URL="http://www.rfc-editor.org/rfc/rfc56.txt"
}

@TECHREPORT{rfc57,
AUTHOR="M. F. Kraley and J. Newkirk",
TITLE="Thoughts and Reflections on {NWG/RFC} 54",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=57,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=1970,
URL="http://www.rfc-editor.org/rfc/rfc57.txt"
}

@TECHREPORT{rfc58,
AUTHOR="T. P. Skinner",
TITLE="Logical Message Synchronization",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=58,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1970,
ABSTRACT="A discussion on a question raised at the last network meeting
regarding the question of logical and physical message distinctions.",
URL="http://www.rfc-editor.org/rfc/rfc58.txt"
}

@TECHREPORT{rfc59,
AUTHOR="E. Meyer",
TITLE="Flow Control - Fixed Versus Demand Allocation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=59,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1970,
ABSTRACT="Discussion of the advantages and disadvantages of the method
of flow control as described in RFC 54.",
URL="http://www.rfc-editor.org/rfc/rfc59.txt"
}

@TECHREPORT{rfc60,
AUTHOR="R. B. Kalin",
TITLE="Simplified {NCP} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=60,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1970,
ABSTRACT="Definition of 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.",
URL="http://www.rfc-editor.org/rfc/rfc60.txt"
}

@TECHREPORT{rfc61,
AUTHOR="D. C. Walden",
TITLE="Note on Interprocess Communication in a Resource Sharing Computer Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=61,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=1970,
ABSTRACT="A draft request for comments of a resource sharing study that
may be of general interest to network participants.",
URL="http://www.rfc-editor.org/rfc/rfc61.txt"
}

@TECHREPORT{rfc62,
AUTHOR="D. C. Walden",
TITLE="Systems for Interprocess Communication in a Resource Sharing Computer
Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=62,
PAGES=20,
DAYS=15,
MONTH=aug,
YEAR=1970,
ABSTRACT="Supercedes RFC 61.",
URL="http://www.rfc-editor.org/rfc/rfc62.txt"
}

@TECHREPORT{rfc63,
AUTHOR="V. G. Cerf",
TITLE="Belated Network Meeting Report",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=63,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1970,
ABSTRACT="Network meeting report of the Network Working Group from 8 May
70.",
URL="http://www.rfc-editor.org/rfc/rfc63.txt"
}

@TECHREPORT{rfc64,
AUTHOR="M. Elie",
TITLE="Getting rid of marking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=64,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1970,
ABSTRACT="Suggests simple modifications and solutions to the IMP-HOST
interface which would be a better solution than marking.",
URL="http://www.rfc-editor.org/rfc/rfc64.txt"
}

@TECHREPORT{rfc65,
AUTHOR="D. C. Walden",
TITLE="Comments on {Host/Host} Protocol document {#1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=65,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1970,
ABSTRACT="Critique and suggestions for improvement of the Host-Host
Protocol document.",
URL="http://www.rfc-editor.org/rfc/rfc65.txt"
}

@TECHREPORT{rfc66,
AUTHOR="S. D. Crocker",
TITLE="{NIC} - third level ideas and other noise",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=66,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1970,
ABSTRACT="Meeting notes from 12 Aug 70 between Crocker and
representatives from BBN and MIT regarding the third level protocol.",
URL="http://www.rfc-editor.org/rfc/rfc66.txt"
}

@TECHREPORT{rfc67,
AUTHOR="William R. Crowther",
TITLE="Proposed Change to {Host/IMP} Spec to Eliminate Marking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=67,
PAGES=1,
DAYS=15,
MONTH=jan,
YEAR=1970,
ABSTRACT="Proposed change to eliminate marking, per Walden's comments.",
URL="http://www.rfc-editor.org/rfc/rfc67.txt"
}

@TECHREPORT{rfc68,
AUTHOR="M. Elie",
TITLE="Comments on Memory Allocation Control Commands: {CEASE,} {ALL,} {GVB,}
{RET,} and {RFNM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=68,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1970,
ABSTRACT="Provides a scheme for buffer allocation.",
URL="http://www.rfc-editor.org/rfc/rfc68.txt"
}

@TECHREPORT{rfc69,
AUTHOR="A. K. Bhushan",
TITLE="Distribution List Change for {MIT}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=69,
PAGES=1,
DAYS=15,
MONTH=sep,
YEAR=1970,
ABSTRACT="Announcement of name change.",
URL="http://www.rfc-editor.org/rfc/rfc69.txt"
}

@TECHREPORT{rfc70,
AUTHOR="S. D. Crocker",
TITLE="Note on Padding",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=70,
PAGES=9,
DAYS=15,
MONTH=oct,
YEAR=1970,
ABSTRACT="Discussion of padding on a message.",
URL="http://www.rfc-editor.org/rfc/rfc70.txt"
}

@TECHREPORT{rfc71,
AUTHOR="T. Schipper",
TITLE="Reallocation in Case of Input Error",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=71,
DAYS=15,
MONTH=sep,
YEAR=1970,
ABSTRACT="Discussion of how to resynchronize flow control using a
proposed protocol for the CCN-Host at UCLA.",
URL="http://www.rfc-editor.org/rfc/rfc71.txt"
}

@TECHREPORT{rfc72,
AUTHOR="R. D. Bressler",
TITLE="Proposed Moratorium on Changes to Network Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=72,
PAGES=3,
DAYS=15,
MONTH=sep,
YEAR=1970,
ABSTRACT="Cites critical changes that could occur in hardware/software
development efforts and advanced debugging if changes in the Network
Protocol aren't kept in check.",
URL="http://www.rfc-editor.org/rfc/rfc72.txt"
}

@TECHREPORT{rfc73,
AUTHOR="S. D. Crocker",
TITLE="Response to {NWG/RFC} 67",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=73,
PAGES=1,
DAYS=15,
MONTH=sep,
YEAR=1970,
ABSTRACT="General agreement with proposed policy.",
URL="http://www.rfc-editor.org/rfc/rfc73.txt"
}

@TECHREPORT{rfc74,
AUTHOR="J. A. White",
TITLE="Specifications for network use of the {UCSB} {On-Line} System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=74,
DAYS=15,
MONTH=oct,
YEAR=1970,
ABSTRACT="Announcement of UCSB's On-Line System (OLS) availability to
ARPA Network users."
}

@TECHREPORT{rfc76,
AUTHOR="J. Bouknight and J. Madden and Gary R. Grossman",
TITLE="Connection by name: User oriented protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=76,
PAGES=15,
DAYS=15,
MONTH=oct,
YEAR=1970,
ABSTRACT="Suggests a user level interface to network protocol where all
user protocol is handled symbolically with system procedures making the
translation into host-to-host protocol. Proposes general solutions.",
URL="http://www.rfc-editor.org/rfc/rfc76.txt"
}

@TECHREPORT{rfc77,
AUTHOR="J. B. Postel",
TITLE="Network meeting report",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=77,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=1970,
ABSTRACT="Report on three Network Working Group meetings held during
November 16, 17, and 18.",
URL="http://www.rfc-editor.org/rfc/rfc77.txt"
}

@TECHREPORT{rfc78,
AUTHOR="E. Harslem and John F. Heafner and J. A. White",
TITLE="{NCP} Status Report: {UCSB/Rand}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=78,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1970,
ABSTRACT="Conducted an excercise between UCSB console to/from RAND
console validation of the respective NCPs.",
URL="http://www.rfc-editor.org/rfc/rfc78.txt"
}

@TECHREPORT{rfc79,
AUTHOR="E. Meyer",
TITLE="Logger Protocol error",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=79,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1970,
URL="http://www.rfc-editor.org/rfc/rfc79.txt"
}

@TECHREPORT{rfc80,
AUTHOR="E. Harslem and John F. Heafner",
TITLE="Protocols and Data Formats",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=80,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=1970,
ABSTRACT="Proposes general solutions concerning Initial Connection
Protocols, Pre-specificed Data Formats, and Adaptable Mechanisms.",
URL="http://www.rfc-editor.org/rfc/rfc80.txt"
}

@TECHREPORT{rfc81,
AUTHOR="J. Bouknight",
TITLE="Request for Reference Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=81,
PAGES=1,
DAYS=15,
MONTH=dec,
YEAR=1970,
ABSTRACT="Request for documents in the subject areas of data
communications and communications theory.",
URL="http://www.rfc-editor.org/rfc/rfc81.txt"
}

@TECHREPORT{rfc82,
AUTHOR="E. Meyer",
TITLE="Network Meeting Notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=82,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=1970,
ABSTRACT="A transcribed summary of the Fall 1970 network meeting notes.",
URL="http://www.rfc-editor.org/rfc/rfc82.txt"
}

@TECHREPORT{rfc83,
AUTHOR="Ross  Anderson and E. Harslem and John F. Heafner",
TITLE="Language-machine for data reconfiguration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=83,
PAGES=13,
DAYS=15,
MONTH=dec,
YEAR=1970,
ABSTRACT="Describes a syntax-driven interpreter that operates on a
grammar which is an orderd set of replacement rules for the Form
Machine.",
URL="http://www.rfc-editor.org/rfc/rfc83.txt"
}

@TECHREPORT{rfc84,
AUTHOR="J. B. North",
TITLE="List of {NWG/RFC's} {1-80}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=84,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1970,
ABSTRACT="Lists RFCs 1-80.",
URL="http://www.rfc-editor.org/rfc/rfc84.txt"
}

@TECHREPORT{rfc85,
AUTHOR="S. D. Crocker",
TITLE="Network Working Group meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=85,
PAGES=1,
DAYS=15,
MONTH=dec,
YEAR=1970,
ABSTRACT="Announcement of regularly scheduled Network Working Group
Meetings every three months.",
URL="http://www.rfc-editor.org/rfc/rfc85.txt"
}

@TECHREPORT{rfc91,
AUTHOR="G. H. Mealy",
TITLE="Proposed {User-User} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=91,
PAGES=12,
DAYS=15,
MONTH=dec,
YEAR=1970,
ABSTRACT="Discussion of UCLA's Campus Computing Network of services and
implementation priorities.",
URL="http://www.rfc-editor.org/rfc/rfc91.txt"
}

@TECHREPORT{rfc100,
AUTHOR="P. M. Karp",
TITLE="Categorization and guide to {NWG/RFCs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=100,
PAGES=37,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="Categorizes, identifies, and summarizes RFCS 1-100.",
URL="http://www.rfc-editor.org/rfc/rfc100.txt"
}

@TECHREPORT{rfc101,
AUTHOR="R. W. Watson",
TITLE="Notes on the Network Working Group meeting, Urbana, Illinois, February
{17,} 1971",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=101,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="Transcript of the Network Working Group Meeting, February
1970.",
URL="http://www.rfc-editor.org/rfc/rfc101.txt"
}

@TECHREPORT{rfc102,
AUTHOR="S. D. Crocker",
TITLE="Output of the {Host-Host} Protocol glitch cleaning committee",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=102,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="Numerous topics were discussed.",
URL="http://www.rfc-editor.org/rfc/rfc102.txt"
}

@TECHREPORT{rfc103,
AUTHOR="R. B. Kalin",
TITLE="Implementation of Interrupt Keys",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=103,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="This paper discusses the problems and solutions that are
simple to implement in the current protocol specifications that contain
serious logical errors in the interrupt functions.",
URL="http://www.rfc-editor.org/rfc/rfc103.txt"
}

@TECHREPORT{rfc104,
AUTHOR="J. B. Postel and S. D. Crocker",
TITLE="Link 191",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=104,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="General agreement to reserve a link for use in measurements.
Therefore, Link 191 will be assigned for measurement use.",
URL="http://www.rfc-editor.org/rfc/rfc104.txt"
}

@TECHREPORT{rfc105,
AUTHOR="J. A. White",
TITLE="Network Specifications for Remote Job Entry and Remote Job Output Retrieval
at {UCSB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=105,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1971,
ABSTRACT="Describes the remote job entry service at UCSB.",
URL="http://www.rfc-editor.org/rfc/rfc105.txt"
}

@TECHREPORT{rfc106,
AUTHOR="T. C. O'Sullivan",
TITLE="{User/Server} Site Protocol Network Host Questionnaire",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=106,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1971,
ABSTRACT="An attempt to gather information for creating the Telnet
Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc106.txt"
}

@TECHREPORT{rfc108,
AUTHOR="R. W. Watson",
TITLE="Attendance list at the Urbana {NWG} meeting, February {17-19,} 1971",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=108,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1971,
ABSTRACT="Lists attendees at the NWG meeting held February 1971.",
URL="http://www.rfc-editor.org/rfc/rfc108.txt"
}

@TECHREPORT{rfc109,
AUTHOR="J. M. Winett",
TITLE="Level {III} Server Protocol for the Lincoln Laboratory {NIC} {360/67} Host",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=109,
DAYS=15,
MONTH=mar,
YEAR=1971,
ABSTRACT="Telnet implementation and the 360/67."
}

@TECHREPORT{rfc110,
AUTHOR="J. M. Winett",
TITLE="Conventions for using an {IBM} 2741 terminal as a user console for access
to network server hosts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=110,
DAYS=15,
MONTH=mar,
YEAR=1971,
ABSTRACT="Telnet implementation and the 2741."
}

@TECHREPORT{rfc111,
AUTHOR="S. D. Crocker",
TITLE="Pressure from the Chairman",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=111,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1971,
ABSTRACT="Proposed scheduling for the implementation of NCPs and
Telnets.",
URL="http://www.rfc-editor.org/rfc/rfc111.txt"
}

@TECHREPORT{rfc112,
AUTHOR="T. C. O'Sullivan",
TITLE="{User/Server} Site Protocol: Network host questionnaire responses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=112,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="A summary of the responses to the referenced questionnaire."
}

@TECHREPORT{rfc113,
AUTHOR="E. Harslem and John F. Heafner and J. A. White",
TITLE="Network activity report: {UCSB} Rand",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=113,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Report on the network use and validity between UCSB's RJE and
RJOR systems and RAND.",
URL="http://www.rfc-editor.org/rfc/rfc113.txt"
}

@TECHREPORT{rfc114,
AUTHOR="A. K. Bhushan",
TITLE="File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=114,
PAGES=17,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Proposed file transfer mechanisms that have been developed for
immediate implementation on hosts at MIT.",
URL="http://www.rfc-editor.org/rfc/rfc114.txt"
}

@TECHREPORT{rfc115,
AUTHOR="R. W. Watson and J. B. North",
TITLE="Some Network Information Center policies on handling documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=115,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Discusses current document policies between the Network
Information Center and sites on the network.",
URL="http://www.rfc-editor.org/rfc/rfc115.txt"
}

@TECHREPORT{rfc116,
AUTHOR="S. D. Crocker",
TITLE="Structure of the May {NWG} Meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=116,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Proposed meeting agenda centering around discussions of
advertised topics, with published status reports and position papers.",
URL="http://www.rfc-editor.org/rfc/rfc116.txt"
}

@TECHREPORT{rfc117,
AUTHOR="J. W. Wong",
TITLE="Some comments on the official protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=117,
PAGES=5,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Cites weaknesses in RFC 107, and provides suggestions for
correction and handling.",
URL="http://www.rfc-editor.org/rfc/rfc117.txt"
}

@TECHREPORT{rfc118,
AUTHOR="R. W. Watson",
TITLE="Recommendations for facility documentation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=118,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Cites two classes of information which each site needs to
provide for every service or process it makes available over the ARPA
network.",
URL="http://www.rfc-editor.org/rfc/rfc118.txt"
}

@TECHREPORT{rfc119,
AUTHOR="M. Krilanovich",
TITLE="Network Fortran subprograms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=119,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Descriptions of a set of assembly-language subprograms, their
functions and calling sequences."
}

@TECHREPORT{rfc120,
AUTHOR="M. Krilanovich",
TITLE="Network {PL1} subprograms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=120,
PAGES=16,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Descriptions of subroutines that have been implemented at UCSB
and make the network (via NCP) accessible to PL1 programs executing in
the IBM 360/75.",
URL="http://www.rfc-editor.org/rfc/rfc120.txt"
}

@TECHREPORT{rfc121,
AUTHOR="M. Krilanovich",
TITLE="Network on-line operators",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=121,
PAGES=13,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Descriptions of operators that have been implemented within
UCSB's On-Line System and make the network (via NCP) accessible to
On-Line system users.",
URL="http://www.rfc-editor.org/rfc/rfc121.txt"
}

@TECHREPORT{rfc122,
AUTHOR="J. A. White",
TITLE="Network specifications for {UCSB's} {Simple-Minded} File System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=122,
PAGES=21,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="UCSB's Simple Minded File System (SMFS) which will provide
file storage for network users. This document provides programmers with
the information necessary to communicate with SMFS.",
URL="http://www.rfc-editor.org/rfc/rfc122.txt"
}

@TECHREPORT{rfc123,
AUTHOR="S. D. Crocker",
TITLE="Proffered Official {ICP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=123,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Description of a family of ICPs (Initial Connection Protocol)
suitable for establishing one pair of connections (one in each
direction) between any user process and any server process, and proposes
a particular subset of this family as the standard ICP for connecting
user processes to loggers on systems which accept teletype-like devices.",
URL="http://www.rfc-editor.org/rfc/rfc123.txt"
}

@TECHREPORT{rfc124,
AUTHOR="J. T. Melvin",
TITLE="Typographical error in {RFC} 107",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=124,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Points out an error in RFC 107.",
URL="http://www.rfc-editor.org/rfc/rfc124.txt"
}

@TECHREPORT{rfc125,
AUTHOR="J. McConnell",
TITLE="Response to {RFC} {86:} Proposal for Network Standard Format for a Graphics
Data Stream",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=125,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Improves and updates RFC 86.",
URL="http://www.rfc-editor.org/rfc/rfc125.txt"
}

@TECHREPORT{rfc126,
AUTHOR="J. McConnell",
TITLE="Graphics Facilities at Ames Research Center",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=126,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Discusses the graphical facilities at Ames for the IBM 360/67
TSS.",
URL="http://www.rfc-editor.org/rfc/rfc126.txt"
}

@TECHREPORT{rfc127,
AUTHOR="J. B. Postel",
TITLE="Comments on {RFC} 123",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=127,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Continued interpretations of the exchange between NCP's which
would be necessary to carry out the Initial Connection Protocol of RFC
123.",
URL="http://www.rfc-editor.org/rfc/rfc127.txt"
}

@TECHREPORT{rfc128,
AUTHOR="J. B. Postel",
TITLE="Bytes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=128,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Discussion of the Byte size parameter allowed by the 2nd level
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc128.txt"
}

@TECHREPORT{rfc129,
AUTHOR="E. Harslem and J. Heafner and E. Meyer",
TITLE="Request for comments on socket name structure",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=129,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Comments on several suggested socket name structures.",
URL="http://www.rfc-editor.org/rfc/rfc129.txt"
}

@TECHREPORT{rfc130,
AUTHOR="John F. Heafner",
TITLE="Response to {RFC} {111:} Pressure from the chairman",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=130,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Discussion of RAND's role in testing other host
implementations and schedule dependences.",
URL="http://www.rfc-editor.org/rfc/rfc130.txt"
}

@TECHREPORT{rfc131,
AUTHOR="E. Harslem and John F. Heafner",
TITLE="Response to {RFC} {116:} May {NWG} meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=131,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="A description of networr plans at RAND, including the data
reconfiguration service, and a comment on the role of the NWG.",
URL="http://www.rfc-editor.org/rfc/rfc131.txt"
}

@TECHREPORT{rfc133,
AUTHOR="R. L. Sunberg",
TITLE="File Transfer and Error Recovery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=133,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Sample interchanges and comments on file transfer and errors.",
URL="http://www.rfc-editor.org/rfc/rfc133.txt"
}

@TECHREPORT{rfc134,
AUTHOR="A. Vezza",
TITLE="Network Graphics meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=134,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Announcement of the next Network Graphics Meeting at Project
MAC in July 1971.",
URL="http://www.rfc-editor.org/rfc/rfc134.txt"
}

@TECHREPORT{rfc135,
AUTHOR="W. Hathaway",
TITLE="Response to {NWG/RFC} 110",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=135,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Comments and proposals of new conventions to replace the ones
proposed in RFC 110.",
URL="http://www.rfc-editor.org/rfc/rfc135.txt"
}

@TECHREPORT{rfc136,
AUTHOR="R. E. Kahn",
TITLE="Host accounting and administrative procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=136,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Discussion of a plan to be formulated and accepted for the
development of a Host accounting system in the ARPA Network.",
URL="http://www.rfc-editor.org/rfc/rfc136.txt"
}

@TECHREPORT{rfc137,
AUTHOR="T. C. O'Sullivan",
TITLE="Telnet Protocol - a proposed document",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=137,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Solicitation for review and comment before the Atlantic City
NWG meetings.",
URL="http://www.rfc-editor.org/rfc/rfc137.txt"
}

@TECHREPORT{rfc138,
AUTHOR="Ross  Anderson and V. G. Cerf and E. Harslem and John F. Heafner and J.
Madden and Robert M. Metcalfe and A. Shoshani and J. A. White",
TITLE="Status report on proposed Data Reconfiguration Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=138,
PAGES=23,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Provides a description of a proposed Network experiment and to
solicit comments on any aspect of the experiment.",
URL="http://www.rfc-editor.org/rfc/rfc138.txt"
}

@TECHREPORT{rfc139,
AUTHOR="T. C. O'Sullivan",
TITLE="Discussion of Telnet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=139,
PAGES=11,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="An extension of RFC 137.",
URL="http://www.rfc-editor.org/rfc/rfc139.txt"
}

@TECHREPORT{rfc140,
AUTHOR="S. D. Crocker",
TITLE="Agenda for the May {NWG} meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=140,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="A list of topics to be discussed at the upcoming meeting, plus
a listing of relevant RFCs that should be reviewed prior to the meeting.",
URL="http://www.rfc-editor.org/rfc/rfc140.txt"
}

@TECHREPORT{rfc141,
AUTHOR="E. Harslem and John F. Heafner",
TITLE="Comments on {RFC} {114:} A File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=141,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Further discussion on the File Transfer Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc141.txt"
}

@TECHREPORT{rfc142,
AUTHOR="C. S. Kline and J. W. Wong",
TITLE="{Time-Out} Mechanism in the {Host-Host} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=142,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Discussion on potential situations that can occur when sending
a message to a foreign site.",
URL="http://www.rfc-editor.org/rfc/rfc142.txt"
}

@TECHREPORT{rfc143,
AUTHOR="W. E. Naylor and J. W. Wong and C. S. Kline and J. B. Postel",
TITLE="Regarding proffered official {ICP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=143,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Comments on a race condition discovered in the ICP as proposed
in RFC 123.",
URL="http://www.rfc-editor.org/rfc/rfc143.txt"
}

@TECHREPORT{rfc144,
AUTHOR="A. Shoshani",
TITLE="Data sharing on computer networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=144,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="An introductory paper for the upcoming NWG meeting in Atlantic
City.",
URL="http://www.rfc-editor.org/rfc/rfc144.txt"
}

@TECHREPORT{rfc145,
AUTHOR="J. B. Postel",
TITLE="Initial Connection Protocol Control Commands",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=145,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="An interpretation of the exchange between NCP's which would be
necessary to carry out the Initial Connection Protocol (ICP) of RFC 123.",
URL="http://www.rfc-editor.org/rfc/rfc145.txt"
}

@TECHREPORT{rfc146,
AUTHOR="P. M. Karp and D. B. McKay and D. P. M.",
TITLE="Views on issues relevant to data sharing on computer networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=146,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Concurrence with the views presented in RFC 140.",
URL="http://www.rfc-editor.org/rfc/rfc146.txt"
}

@TECHREPORT{rfc147,
AUTHOR="J. M. Winett",
TITLE="Definition of a socket",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=147,
PAGES=3,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Defining, specifying, and identifying sockets.",
URL="http://www.rfc-editor.org/rfc/rfc147.txt"
}

@TECHREPORT{rfc149,
AUTHOR="S. D. Crocker",
TITLE="Best Laid Plans",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=149,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Changes to the topics and attendees of the upcoming NWG
meeting.",
URL="http://www.rfc-editor.org/rfc/rfc149.txt"
}

@TECHREPORT{rfc150,
AUTHOR="R. B. Kalin",
TITLE="Use of {IPC} Facilities: A Working Paper",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=150,
PAGES=11,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="A working paper discussing the exposition of the types of
usage to which an IPC facility would be subjected. This document hopes
to clarify the goals being pursued and should provide a benchmark for
gauging various implementation strategies.",
URL="http://www.rfc-editor.org/rfc/rfc150.txt"
}

@TECHREPORT{rfc151,
AUTHOR="A. Shoshani",
TITLE="Comments on a proffered official {ICP:} {RFCs} {123,} 127",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=151,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Specific and general remarks regarding the ICP.",
URL="http://www.rfc-editor.org/rfc/rfc151.txt"
}

@TECHREPORT{rfc152,
AUTHOR="M. Wilber",
TITLE="{SRI} Artificial Intelligence status report",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=152,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Status report on SRAI's connection to the ARPANET as a
research center.",
URL="http://www.rfc-editor.org/rfc/rfc152.txt"
}

@TECHREPORT{rfc153,
AUTHOR="J. T. Melvin and R. W. Watson",
TITLE="{SRI} {ARC-NIC} status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=153,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Discusses the current computer and network status of the SRI
ARC-NIC.",
URL="http://www.rfc-editor.org/rfc/rfc153.txt"
}

@TECHREPORT{rfc154,
AUTHOR="S. D. Crocker",
TITLE="Exposition Style",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=154,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="A note on style in documentation.",
URL="http://www.rfc-editor.org/rfc/rfc154.txt"
}

@TECHREPORT{rfc155,
AUTHOR="J. B. North",
TITLE="{ARPA} Network mailing lists",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=155,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Mailing list of people who are receiving the initial
distribution of RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc155.txt"
}

@TECHREPORT{rfc156,
AUTHOR="J. Bouknight",
TITLE="Status of the Illinois site: Response to {RFC} 116",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=156,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1971,
ABSTRACT="Discusses the status of the operational hardware at the
Illinois site.",
URL="http://www.rfc-editor.org/rfc/rfc156.txt"
}

@TECHREPORT{rfc157,
AUTHOR="V. G. Cerf",
TITLE="Invitation to the Second Symposium on Problems in the Optimization of Data
Communications Systems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=157,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Announcement of an ACM/IEEE conference on data communication.",
URL="http://www.rfc-editor.org/rfc/rfc157.txt"
}

@TECHREPORT{rfc158,
AUTHOR="T. C. O'Sullivan",
TITLE="Telnet Protocol: A Proposed Document",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=158,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Solicitation of comments, evaluation, and requests for
modification of the proposed Telnet protocol."
}

@TECHREPORT{rfc160,
AUTHOR=" {{Network Information Center, Stanford Research Institute}}",
TITLE="{RFC} brief list",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=160,
MONTH=may,
YEAR=1971,
ABSTRACT="Title or Partial Title RFC List (1-160)",
URL="http://www.rfc-editor.org/rfc/rfc160.txt"
}

@TECHREPORT{rfc161,
AUTHOR="A. Shoshani",
TITLE="Solution to the race condition in the {ICP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=161,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="A proposed solution to a problem that arose out of RFC 143.",
URL="http://www.rfc-editor.org/rfc/rfc161.txt"
}

@TECHREPORT{rfc162,
AUTHOR="M. Kampe",
TITLE="{NETBUGGER3}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=162,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="Discussion of NETBUGGER3 as a third level program for the
debugging of second and third level programs, experimentation with and
simulation of third level protocols.",
URL="http://www.rfc-editor.org/rfc/rfc162.txt"
}

@TECHREPORT{rfc163,
AUTHOR="V. G. Cerf",
TITLE="Data transfer protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=163,
PAGES=3,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="An informal statement on Data Transfer Protocols, in relation
to material discussed at the SJCC.",
URL="http://www.rfc-editor.org/rfc/rfc163.txt"
}

@TECHREPORT{rfc164,
AUTHOR="John F. Heafner",
TITLE="Minutes of Network Working Group meeting, {5/16} through {5/19/71}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=164,
PAGES=32,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="A 38 page reference on the discussions held at the Network
Working Group Meeting.",
URL="http://www.rfc-editor.org/rfc/rfc164.txt"
}

@TECHREPORT{rfc165,
AUTHOR="J. B. Postel",
TITLE="Proffered official Initial Connection Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=165,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="This document specifies the third level protocol used to
connect a user process at one site with a server process at another
site."
}

@TECHREPORT{rfc166,
AUTHOR="Ross  Anderson and V. G. Cerf and E. Harslem and John F. Heafner and J.
Madden and Robert M. Metcalfe and A. Shoshani and J. A. White",
TITLE="Data Reconfiguration Service: An implementation specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=166,
PAGES=20,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="This DRS experiment involved a software mechanism to reformat
Network data streams. The mechanism can be adapted to numerous Network
application programs.",
URL="http://www.rfc-editor.org/rfc/rfc166.txt"
}

@TECHREPORT{rfc167,
AUTHOR="A. K. Bhushan and Robert M. Metcalfe and J. M. Winett",
TITLE="Socket conventions reconsidered",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=167,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1971,
ABSTRACT="The recent NCP Protocol said nothing about how hosts should
assign socket numbers to process ports, except that the low-order bit is
to specify socket gender. This document discusses two recent proposals
that call for additional network-wide conventions on the 32-bit socket
number.",
URL="http://www.rfc-editor.org/rfc/rfc167.txt"
}

@TECHREPORT{rfc169,
AUTHOR="S. D. Crocker",
TITLE="Computer networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=169,
DAYS=15,
MONTH=may,
YEAR=1971
}

@TECHREPORT{rfc170,
AUTHOR=" {{Network Information Center, Stanford Research Institute}}",
TITLE="{RFC} List by Number",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=170,
MONTH=jun,
YEAR=1971,
ABSTRACT="A list of RFCs 1-170.",
URL="http://www.rfc-editor.org/rfc/rfc170.txt"
}

@TECHREPORT{rfc171,
AUTHOR="A. K. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner
and A. McKenize and J. T. Melvin and B. Sundberg",
TITLE="The Data Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=171,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="Definition of a low-level Data Transfer Protocol (DTP) to be
used for transfer of data in file transfer, remote job entry, and other
applications oriented protocols. A companion paper (RFC 172) describes
file transfer protocol.",
URL="http://www.rfc-editor.org/rfc/rfc171.txt"
}

@TECHREPORT{rfc172,
AUTHOR="A. K. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner
and A. A. McKenzie and J. T. Melvin and B. Sundberg",
TITLE="The File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=172,
PAGES=12,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="This protocol is a user-level protocol for file transfer
between host computers (including terminal IMPs), on the ARPA computer
network. The File Transfer Protocol (FTP) uses the data transfer
protocol described in RFC 171. This paper assumes knowledge of RFC 171.",
URL="http://www.rfc-editor.org/rfc/rfc172.txt"
}

@TECHREPORT{rfc173,
AUTHOR="P. M. Karp and D. B. McKay",
TITLE="Network Data Management Committee Meeting Announcement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=173,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="A report on the formation of a data managment committee and on
its first meeting.",
URL="http://www.rfc-editor.org/rfc/rfc173.txt"
}

@TECHREPORT{rfc174,
AUTHOR="J. B. Postel and V. G. Cerf",
TITLE="{UCLA} - Computer Science Graphics Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=174,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="This document provides an overview of the hardware, software,
and intentions of the UCLA Computer Science Department's Graphics
project.",
URL="http://www.rfc-editor.org/rfc/rfc174.txt"
}

@TECHREPORT{rfc175,
AUTHOR="E. Harslem and John F. Heafner",
TITLE={Comments on {"}Socket Conventions Reconsidered{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=175,
PAGES=1,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="Pro and con discussion regarding RFC 167.",
URL="http://www.rfc-editor.org/rfc/rfc175.txt"
}

@TECHREPORT{rfc176,
AUTHOR="A. K. Bhushan and R. Kanodia and Robert M. Metcalfe and J. B. Postel",
TITLE={Comments on {"}Byte size for connections{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=176,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="This document points out three views on the use of byte size
for network connections: 1) Byte size should not be used at all. 2) Byte
size is solely for the convenience of NCP's. 3) Byte size choice is a
user-level prerogative.",
URL="http://www.rfc-editor.org/rfc/rfc176.txt"
}

@TECHREPORT{rfc177,
AUTHOR="J. McConnell",
TITLE="Device independent graphical display description",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=177,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc177.txt"
}

@TECHREPORT{rfc178,
AUTHOR="I. W. Cotton",
TITLE="Network graphic attention handling",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=178,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="The process of attention handling is briefly described,
various graphic configurations are discussed, input devices are surveyed
to identify the types of data which they produce, and an attention
protocol is proposed.",
URL="http://www.rfc-editor.org/rfc/rfc178.txt"
}

@TECHREPORT{rfc179,
AUTHOR="A. A. McKenzie",
TITLE="Link Number Assignments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=179,
PAGES=1,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc179.txt"
}

@TECHREPORT{rfc180,
AUTHOR="A. A. McKenzie",
TITLE="File system questionnaire",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=180,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="An attempt to gather information about local file and data
conventions.",
URL="http://www.rfc-editor.org/rfc/rfc180.txt"
}

@TECHREPORT{rfc181,
AUTHOR="J. McConnell",
TITLE="Modifications to {RFC} 177",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=181,
PAGES=3,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="This document is intended to modify the proposal for a device
independent graphical display description discussed in RFC 177. The main
changes are in the definition of coordinate areas to avoid one problem
encountered with the old definition and to provide more flexibility.",
URL="http://www.rfc-editor.org/rfc/rfc181.txt"
}

@TECHREPORT{rfc182,
AUTHOR="J. B. North",
TITLE="Compilation of list of relevant site reports",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=182,
PAGES=1,
DAYS=15,
MONTH=jun,
YEAR=1971,
ABSTRACT="A Network Information Center compilation list of all
site-produced reports which are of interest to Network participants.",
URL="http://www.rfc-editor.org/rfc/rfc182.txt"
}

@TECHREPORT{rfc183,
AUTHOR="J. M. Winett",
TITLE="{EBCDIC} codes and their mapping to {ASCII}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=183,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="This document defines and describes the IBM Standard Extended
BCD Interchange Code. This is done in order to uniquely map the ASCII
codes into corresponding EBCDIC codes in a consistent manner throughout
the ARPA Network."
}

@TECHREPORT{rfc184,
AUTHOR="K. C. Kelley",
TITLE="Proposed graphic display modes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=184,
PAGES=7,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="The ARPA Network node at the University of Illinois' Center
for Advanced Computation is different from other nodes. It is not just a
simple attachment to the net. Establishment of the computer system
specifically for use of the ILLIAC IV and the network is in process.
This paper describes the operating systems, network interface and
utility routines, and ILLIAC IV routines to be used over the network.",
URL="http://www.rfc-editor.org/rfc/rfc184.txt"
}

@TECHREPORT{rfc185,
AUTHOR="J. B. North",
TITLE="{NIC} distribution of manuals and handbooks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=185,
PAGES=1,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="The NIC request that sites send copies of manuals and
handbooks to them.",
URL="http://www.rfc-editor.org/rfc/rfc185.txt"
}

@TECHREPORT{rfc186,
AUTHOR="J. C. Michener",
TITLE="Network graphics loader",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=186,
PAGES=17,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="The Network Graphics Loader described in this document
proposes to permit remote users on the ARPA network to obtain graphics
output from programs they write for the Evans and Sutherland Line
Drawing System.",
URL="http://www.rfc-editor.org/rfc/rfc186.txt"
}

@TECHREPORT{rfc187,
AUTHOR="D. B. McKay and D. P. Karp",
TITLE="Network/440 Protocol Concept",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=187,
PAGES=11,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="An information Request for Comments that is intended to convey
some of the thinking and philosophy that went into IBM's network
protocol and overall network design.",
URL="http://www.rfc-editor.org/rfc/rfc187.txt"
}

@TECHREPORT{rfc188,
AUTHOR="P. M. Karp and D. B. McKay",
TITLE="Data management meeting announcement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=188,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1971,
ABSTRACT="Plans for a data management meeting to be held Auguest 1971.",
URL="http://www.rfc-editor.org/rfc/rfc188.txt"
}

@TECHREPORT{rfc189,
AUTHOR="R. Braden",
TITLE="Interim {NETRJS} specifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=189,
PAGES=19,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="A description of the operation and protocol of the remote job
entry service to CCN's 360 Model 91. This interim protocol will be
implemented as a production service before the end of July.",
URL="http://www.rfc-editor.org/rfc/rfc189.txt"
}

@TECHREPORT{rfc190,
AUTHOR="L. P. Deutsch",
TITLE="{DEC} {PDP-10-IMLAC} communications system",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=190,
PAGES=16,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="This document describes an operational system for
communicating textual display information between a main-site computer
and a remote display processor.",
URL="http://www.rfc-editor.org/rfc/rfc190.txt"
}

@TECHREPORT{rfc191,
AUTHOR="C. Irby",
TITLE="Graphics implementation and conceptualization at Augmentation Research
Center",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=191,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="A brief description of the way in which graphics terminals are
conceptualized and used at the Augmentation Research Center.",
URL="http://www.rfc-editor.org/rfc/rfc191.txt"
}

@TECHREPORT{rfc192,
AUTHOR="R. W. Watson",
TITLE="Some factors which a Network Graphics Protocol must consider",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=192,
PAGES=19,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="Discussion on what any network graphics protocol should come
to grips with.",
URL="http://www.rfc-editor.org/rfc/rfc192.txt"
}

@TECHREPORT{rfc193,
AUTHOR="E. Harslem and John F. Heafner",
TITLE="{NETWORK} {CHECKOUT}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=193,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="A report form RAND on testing ten other hosts.",
URL="http://www.rfc-editor.org/rfc/rfc193.txt"
}

@TECHREPORT{rfc194,
AUTHOR="V. G. Cerf and E. Harslem and J. Heafner and B. Metcalfe and J. A. White",
TITLE="The data reconfiguration service {--} compiler/interpreter implementation
notesThe Data Reconfiguration Service {--} {Compiler/Interpreter}
Implementation Notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=194,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="This document describes the new features of the language, the
new syntax, the form interpreter, and the instruction set.",
URL="http://www.rfc-editor.org/rfc/rfc194.txt"
}

@TECHREPORT{rfc195,
AUTHOR="G. H. Mealy",
TITLE="Data computers-data descriptions and access language",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=195,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="This document discusses some of the problems involved in the
unified approach to Network data management, and to suggest possible
avenues of approach toward their resolution.",
URL="http://www.rfc-editor.org/rfc/rfc195.txt"
}

@TECHREPORT{rfc196,
AUTHOR="R. W. Watson",
TITLE="Mail Box Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=196,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc196.txt"
}

@TECHREPORT{rfc197,
AUTHOR="A. Shoshani and E. Harslem",
TITLE="Initial Connection Protocol - Reviewed",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=197,
PAGES=5,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="An attempt at a simple version of ICP, assuming one may add
commands to Host-Host protocol.",
URL="http://www.rfc-editor.org/rfc/rfc197.txt"
}

@TECHREPORT{rfc198,
AUTHOR="John F. Heafner",
TITLE="Site Certification - Lincoln Labs {360/67}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=198,
PAGES=1,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="A report from RAND that Lincoln Labs protocol implementations
are correct.",
URL="http://www.rfc-editor.org/rfc/rfc198.txt"
}

@TECHREPORT{rfc199,
AUTHOR="T. Williams",
TITLE="Suggestions for a network data-tablet graphics protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=199,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="SDC's comments to the discussion of a protocol for network
graphics within the ARPA Network community. Concern is focused on the
development of the graphics protocol in two areas: non-interactive
graphics and data-tablet graphics, as opposed to fully interactive
graphics."
}

@TECHREPORT{rfc202,
AUTHOR="S. M. Wolfe and J. B. Postel",
TITLE="Possible Deadlock in {ICP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=202,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="A notation of a possible deadlock that will occur if both
sides open thier send or both sides open their receive sockets first.",
URL="http://www.rfc-editor.org/rfc/rfc202.txt"
}

@TECHREPORT{rfc203,
AUTHOR="R. B. Kalin",
TITLE="Achieving reliable communication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=203,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="This is a non-standard protocol, suitable for either second or
third level use and is proposed with the intent of providing error
resistant and highly reliable communication channels.",
URL="http://www.rfc-editor.org/rfc/rfc203.txt"
}

@TECHREPORT{rfc204,
AUTHOR="J. B. Postel",
TITLE="Sockets in use",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=204,
PAGES=1,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="Announcement to collect information on the use of socket
numbers for standard service programs.",
URL="http://www.rfc-editor.org/rfc/rfc204.txt"
}

@TECHREPORT{rfc205,
AUTHOR="R. Braden",
TITLE="{NETCRT} - a character display protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=205,
PAGES=13,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="A significant revision of the character-display protocol
(NETCRT), based on CCN's proposed NETCRT from the May NWG Meeting.",
URL="http://www.rfc-editor.org/rfc/rfc205.txt"
}

@TECHREPORT{rfc206,
AUTHOR="J. A. White",
TITLE="User Telnet - description of an initial implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=206,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="This document describes a program whose function is to make an
Online System terminal appear to any teletype-compatible, time-sharing
system in the Network as if it were directly connected to that system."
}

@TECHREPORT{rfc207,
AUTHOR="A. Vezza",
TITLE="September Network Working Group meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=207,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="Next meeting announcement.",
URL="http://www.rfc-editor.org/rfc/rfc207.txt"
}

@TECHREPORT{rfc208,
AUTHOR="A. A. McKenzie",
TITLE="Address tables",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=208,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="A table of hosts on or soon to be on the ARPANET.",
URL="http://www.rfc-editor.org/rfc/rfc208.txt"
}

@TECHREPORT{rfc209,
AUTHOR="B. Cosell",
TITLE="{Host/IMP} interface documentation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=209,
PAGES=1,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="Discussion of a change to the IMP and the documentation (BBN
report 1822).",
URL="http://www.rfc-editor.org/rfc/rfc209.txt"
}

@TECHREPORT{rfc210,
AUTHOR="W. Conrad",
TITLE="Improvement of Flow Control",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=210,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT={Discussion of the current {"}give back{"} - {"}return{"} scheme.},
URL="http://www.rfc-editor.org/rfc/rfc210.txt"
}

@TECHREPORT{rfc212,
AUTHOR=" {{Information Sciences Institute University of Southern California}}",
TITLE="{NWG} meeting on network usage",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=212,
MONTH=aug,
YEAR=1971,
ABSTRACT="A mailing list for RFC distribution.",
URL="http://www.rfc-editor.org/rfc/rfc212.txt"
}

@TECHREPORT{rfc213,
AUTHOR="B. Cosell",
TITLE="{IMP} System change notification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=213,
PAGES=1,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="Several changes in the IMP internal procedures.",
URL="http://www.rfc-editor.org/rfc/rfc213.txt"
}

@TECHREPORT{rfc214,
AUTHOR="E. Harslem",
TITLE="Network checkpoint",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=214,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="Notification of the verification of certain sites.",
URL="http://www.rfc-editor.org/rfc/rfc214.txt"
}

@TECHREPORT{rfc215,
AUTHOR="A. A. McKenzie",
TITLE="{NCP,} {ICP,} and Telnet: The Terminal {IMP} implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=215,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="Announcement of six Terminal IMPs being incorporated into the
Network, with additional Terminal IMPS scheduled for delivery.",
URL="http://www.rfc-editor.org/rfc/rfc215.txt"
}

@TECHREPORT{rfc216,
AUTHOR="J. A. White",
TITLE="Telnet access to {UCSB's} {On-Line} System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=216,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Discussion of the implementation of a teletype-compatible
interface to UCSB's On-Line System."
}

@TECHREPORT{rfc217,
AUTHOR="J. A. White",
TITLE="Specifications changes for {OLS,} {RJE/RJOR,} and {SMFS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=217,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Current listing of documents that have been revised.",
URL="http://www.rfc-editor.org/rfc/rfc217.txt"
}

@TECHREPORT{rfc218,
AUTHOR="B. Cosell",
TITLE="Changing the {IMP} status reporting facility",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=218,
PAGES=1,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="A change in internal procedures in the ARPANET status reports
from the IMPs to the NIC.",
URL="http://www.rfc-editor.org/rfc/rfc218.txt"
}

@TECHREPORT{rfc219,
AUTHOR="R. Winter",
TITLE="User's view of the datacomputer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=219,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="A description of the Datacomputer."
}

@TECHREPORT{rfc221,
AUTHOR="R. W. Watson",
TITLE="Mail Box Protocol: Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=221,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1971,
ABSTRACT="Discussion of the initial reaction to RFC 196.",
URL="http://www.rfc-editor.org/rfc/rfc221.txt"
}

@TECHREPORT{rfc222,
AUTHOR="Robert M. Metcalfe",
TITLE="Subject: System programmer's workshop",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=222,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Announcement of the next workshop.",
URL="http://www.rfc-editor.org/rfc/rfc222.txt"
}

@TECHREPORT{rfc223,
AUTHOR="J. T. Melvin and R. W. Watson",
TITLE="Network Information Center schedule for network users",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=223,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Access schedule for remote users of the NIC.",
URL="http://www.rfc-editor.org/rfc/rfc223.txt"
}

@TECHREPORT{rfc224,
AUTHOR="A. A. McKenzie",
TITLE="Comments on Mailbox Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=224,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Comments on electronic mail and TIP's.",
URL="http://www.rfc-editor.org/rfc/rfc224.txt"
}

@TECHREPORT{rfc225,
AUTHOR="E. Harslem and R. Stoughton",
TITLE="{Rand/UCSB} network graphics experiment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=225,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Describes use from RAND of the UCSB-OLS system.",
URL="http://www.rfc-editor.org/rfc/rfc225.txt"
}

@TECHREPORT{rfc226,
AUTHOR="P. M. Karp",
TITLE="Standardization of host mnemonics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=226,
PAGES=1,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="A list of Host Mnemonics is provided.",
URL="http://www.rfc-editor.org/rfc/rfc226.txt"
}

@TECHREPORT{rfc227,
AUTHOR="John F. Heafner and E. Harslem",
TITLE="Data transfer rates {(Rand/UCLA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=227,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="A memo on data rates typical of the RJS use at UCLA CCN.",
URL="http://www.rfc-editor.org/rfc/rfc227.txt"
}

@TECHREPORT{rfc228,
AUTHOR="D. C. Walden",
TITLE="Clarification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=228,
PAGES=1,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="A correction to RFC 70.",
URL="http://www.rfc-editor.org/rfc/rfc228.txt"
}

@TECHREPORT{rfc229,
AUTHOR="J. B. Postel",
TITLE="Standard host names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=229,
PAGES=3,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="A suggestion of eight character names and a proposed list of
names.",
URL="http://www.rfc-editor.org/rfc/rfc229.txt"
}

@TECHREPORT{rfc230,
AUTHOR="T. Pyke",
TITLE="Toward reliable operation of minicomputer-based terminals on a {TIP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=230,
PAGES=3,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Points out inadequate error detection and initiation of
corrective measures in the present protocol for communication between a
TIP and attached terminals. References RFC 203.",
URL="http://www.rfc-editor.org/rfc/rfc230.txt"
}

@TECHREPORT{rfc231,
AUTHOR="John F. Heafner and E. Harslem",
TITLE="Service center standards for remote usage: A user's view",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=231,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="A statement of views on service center standards. An input to
the service center panel discussion of the October Network meeting.",
URL="http://www.rfc-editor.org/rfc/rfc231.txt"
}

@TECHREPORT{rfc232,
AUTHOR="A. Vezza",
TITLE="Postponement of network graphics meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=232,
PAGES=1,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Schedule conflict and postponement of the graphics meeting.",
URL="http://www.rfc-editor.org/rfc/rfc232.txt"
}

@TECHREPORT{rfc233,
AUTHOR="A. K. Bhushan and R. Metcalfe",
TITLE="Standardization of host call letters",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=233,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="A currently recommended list of call letters.",
URL="http://www.rfc-editor.org/rfc/rfc233.txt"
}

@TECHREPORT{rfc234,
AUTHOR="A. Vezza",
TITLE="Network Working Group meeting schedule",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=234,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Plans for a Network Working Group meeting in October 1971.",
URL="http://www.rfc-editor.org/rfc/rfc234.txt"
}

@TECHREPORT{rfc235,
AUTHOR="E. Westheimer",
TITLE="Site status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=235,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Starting with this RFC, BBN will report on the status of most
Network Hosts.",
URL="http://www.rfc-editor.org/rfc/rfc235.txt"
}

@TECHREPORT{rfc237,
AUTHOR="R. W. Watson",
TITLE="{NIC} view of standard host names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=237,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="The NIC strongly favors standardization of host names. In this
RFC, the NIC proposes that any standard naming scheme should take into
account certain considerations.",
URL="http://www.rfc-editor.org/rfc/rfc237.txt"
}

@TECHREPORT{rfc238,
AUTHOR="R. Braden",
TITLE="Comments on {DTP} and {FTP} proposals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=238,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="This RFC updates RFCs 171,172.",
URL="http://www.rfc-editor.org/rfc/rfc238.txt"
}

@TECHREPORT{rfc239,
AUTHOR="R. Braden",
TITLE="Host mnemonics proposed in {RFC} 226 {(NIC} {7625)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=239,
PAGES=1,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Discussion and comments on RFC 226.",
URL="http://www.rfc-editor.org/rfc/rfc239.txt"
}

@TECHREPORT{rfc241,
AUTHOR="A. A. McKenzie",
TITLE="Connecting computers to {MLC} ports",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=241,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1971,
ABSTRACT="Discussion on the pros and cons of computers being connected
through serial communication lines to ports on the Terminal IMP's
Multi-Line Controller (MLC).",
URL="http://www.rfc-editor.org/rfc/rfc241.txt"
}

@TECHREPORT{rfc242,
AUTHOR="L. Haibt and A. Mullery",
TITLE="Data Descriptive Language for Shared Data",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=242,
PAGES=10,
DAYS=15,
MONTH=jul,
YEAR=1971,
ABSTRACT="Discussion of representation differences. Three categories are
defined: very local representation, representation of collections of
data, and other more complex structures that data collections may have.",
URL="http://www.rfc-editor.org/rfc/rfc242.txt"
}

@TECHREPORT{rfc243,
AUTHOR="A. Mullery",
TITLE="Network and data sharing bibliography",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=243,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Updated by RFC 290.",
URL="http://www.rfc-editor.org/rfc/rfc243.txt"
}

@TECHREPORT{rfc245,
AUTHOR="C. Falls",
TITLE="Reservations for Network Group meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=245,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1971,
URL="http://www.rfc-editor.org/rfc/rfc245.txt"
}

@TECHREPORT{rfc247,
AUTHOR="P. M. Karp",
TITLE="Proffered set of standard host names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=247,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Proposed general set of rules for forming Host Names.
Obsoletes RFC 226.",
URL="http://www.rfc-editor.org/rfc/rfc247.txt"
}

@TECHREPORT{rfc249,
AUTHOR="R. F. Borelli",
TITLE="Coordination of equipment and supplies purchase",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=249,
PAGES=2,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Announcement of an agreement reached regarding the study of
the feasibility of a coordinating point for purchases of equipment and
supplies to be used on the network.",
URL="http://www.rfc-editor.org/rfc/rfc249.txt"
}

@TECHREPORT{rfc250,
AUTHOR="H. Brodie",
TITLE="Some thoughts on file transfer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=250,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Further clarification and proposed revision on several aspects
of the proposed Data Transfer Protocol and the File Transfer Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc250.txt"
}

@TECHREPORT{rfc251,
AUTHOR="D. Stern",
TITLE="Weather data",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=251,
PAGES=2,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Announcement of the USAF Environmental Technical Application
Center (ETAC) services in providing weather data for the ARPA Network.",
URL="http://www.rfc-editor.org/rfc/rfc251.txt"
}

@TECHREPORT{rfc252,
AUTHOR="E. Westheimer",
TITLE="Network host status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=252,
PAGES=3,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Updates RFC 240.",
URL="http://www.rfc-editor.org/rfc/rfc252.txt"
}

@TECHREPORT{rfc253,
AUTHOR="J. A. Moorer",
TITLE="Second Network Graphics meeting details",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=253,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Plans for a graphics meeting to be held November 1971. See RFC
282.",
URL="http://www.rfc-editor.org/rfc/rfc253.txt"
}

@TECHREPORT{rfc254,
AUTHOR="A. K. Bhushan",
TITLE="Scenarios for using {ARPANET} computers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=254,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="This document is provided to facilitate the use of ARPANET
host computer systems via the ARPANET. The objective of these scenarios
is to aid a user in sampling host computers on the ARPANET, thereby
stimulating his interest in using the ARPANET."
}

@TECHREPORT{rfc255,
AUTHOR="E. Westheimer",
TITLE="Status of network hosts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=255,
PAGES=2,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Updates RFC 252.",
URL="http://www.rfc-editor.org/rfc/rfc255.txt"
}

@TECHREPORT{rfc256,
AUTHOR="B. Cosell",
TITLE="{IMPSYS} change notification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=256,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1971,
ABSTRACT="Announcement of a new version of the IMP system, Version 2513.",
URL="http://www.rfc-editor.org/rfc/rfc256.txt"
}

@TECHREPORT{rfc263,
AUTHOR="A. A. McKenzie",
TITLE={{"}Very Distant{"} Host interface},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=263,
PAGES=2,
DAYS=15,
MONTH=dec,
YEAR=1971,
ABSTRACT="Discussion on the best solutions to the general problem of
interfacing Hosts to IMPs.",
URL="http://www.rfc-editor.org/rfc/rfc263.txt"
}

@TECHREPORT{rfc268,
AUTHOR="J. B. Postel",
TITLE="Graphics facilities information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=268,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1971,
ABSTRACT="Request for graphics information.",
URL="http://www.rfc-editor.org/rfc/rfc268.txt"
}

@TECHREPORT{rfc269,
AUTHOR="H. Brodie",
TITLE="Some Experience with File Transfer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=269,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1971,
ABSTRACT="Updates RFCs 122,238,172.",
URL="http://www.rfc-editor.org/rfc/rfc269.txt"
}

@TECHREPORT{rfc273,
AUTHOR="R. W. Watson",
TITLE="More on standard host names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=273,
PAGES=3,
DAYS=15,
MONTH=oct,
YEAR=1971,
ABSTRACT="Discussion on the best way to set up naming schemes for
standard Host names.",
URL="http://www.rfc-editor.org/rfc/rfc273.txt"
}

@TECHREPORT{rfc274,
AUTHOR="E. Forman",
TITLE="Establishing a local guide for network usage",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=274,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=1971,
ABSTRACT="Discussion on the best solutions to the general problem of
interfacing Hosts to IMPs.",
URL="http://www.rfc-editor.org/rfc/rfc274.txt"
}

@TECHREPORT{rfc276,
AUTHOR="R. W. Watson",
TITLE="{NIC} course",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=276,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1971,
ABSTRACT="A course announcement from the NIC on the use of its Online
System (NLS).",
URL="http://www.rfc-editor.org/rfc/rfc276.txt"
}

@TECHREPORT{rfc278,
AUTHOR="A. K. Bhushan and R. Braden and E. Harslem and John F. Heafner and A. A.
McKenzie and J. T. Melvin and R. L. Sundberg and R. W. Watson",
TITLE="Revision of the Mail Box Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=278,
PAGES=4,
DAYS=15,
MONTH=nov,
YEAR=1971,
ABSTRACT="This paper obsoletes RFC 221. The changes to RFC 221 are
presented in this document. The protocol is also restated for additional
review.",
URL="http://www.rfc-editor.org/rfc/rfc278.txt"
}

@TECHREPORT{rfc280,
AUTHOR="R. W. Watson",
TITLE="A Draft of Host Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=280,
PAGES=3,
DAYS=15,
MONTH=nov,
YEAR=1971,
ABSTRACT="A proposed list of names for hosts.",
URL="http://www.rfc-editor.org/rfc/rfc280.txt"
}

@TECHREPORT{rfc281,
AUTHOR="A. A. McKenzie",
TITLE="Suggested addition to File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=281,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1971,
ABSTRACT="Suggests an improved restart procedure in FTP.",
URL="http://www.rfc-editor.org/rfc/rfc281.txt"
}

@TECHREPORT{rfc282,
AUTHOR="M. A. Padlipsky",
TITLE="Graphics meeting report",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=282,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1971,
ABSTRACT="Describes a graphics meeting held November 1972.",
URL="http://www.rfc-editor.org/rfc/rfc282.txt"
}

@TECHREPORT{rfc283,
AUTHOR="R. Braden",
TITLE="{NETRJT:} Remote Job Service Protocol for {TIPS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=283,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=1971,
ABSTRACT="Discusses how it may be feasible in the future to use TIPS for
remote job entry in one or more of three ways: attach local card
readers, line printer, and card punches directly to TIP ports, connect a
remote batch terminal to a full-duplex TIP port via a communication
line, and/or use the tape drive, and do card-to-tape and/or
tape-to-print on another computer.",
URL="http://www.rfc-editor.org/rfc/rfc283.txt"
}

@TECHREPORT{rfc285,
AUTHOR="D. Huff",
TITLE="Network graphics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=285,
DAYS=15,
MONTH=dec,
YEAR=1971,
ABSTRACT="This paper is aimed at bringing together the present state of
graphics on the NET for the newcomer and attempting to add a little more
documentation to the current ground covered in graphics research by
ARPA.",
URL="http://www.rfc-editor.org/rfc/rfc285.txt"
}

@TECHREPORT{rfc286,
AUTHOR="E. Forman",
TITLE="Network Library Information System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=286,
PAGES=1,
DAYS=15,
MONTH=dec,
YEAR=1971,
ABSTRACT="This RFC solicites interested parties in the ARPA community to
form a working group whose interests include developing a new system
that would enable computer query of Library holdings. Georgetown
University is currently designing a Learning Resource Center which could
be the prototype of the proposed working group.",
URL="http://www.rfc-editor.org/rfc/rfc286.txt"
}

@TECHREPORT{rfc289,
AUTHOR="R. W. Watson",
TITLE="What we hope is an official list of host names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=289,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1971,
ABSTRACT="An accepted list of official formal host names and nicknames.",
URL="http://www.rfc-editor.org/rfc/rfc289.txt"
}

@TECHREPORT{rfc86,
AUTHOR="S. D. Crocker",
TITLE="Proposal for a Network Standard Format for a Data Stream to Control
Graphics Display",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=86,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1971,
ABSTRACT="Proposes specifying the form of an output stream for the case
that the output portion of the console (which is attached to a computer
at the user's site) is a typical refresh display with point, vector, and
character drawing capability.",
URL="http://www.rfc-editor.org/rfc/rfc86.txt"
}

@TECHREPORT{rfc87,
AUTHOR="A. Vezza",
TITLE="Topic for Discussion at the Next Network Working Group Meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=87,
PAGES=3,
DAYS=15,
MONTH=jan,
YEAR=1971,
ABSTRACT="Suggests Network Working Group discussion on topics germane to
network graphics.",
URL="http://www.rfc-editor.org/rfc/rfc87.txt"
}

@TECHREPORT{rfc88,
AUTHOR="R. Braden and S. M. Wolfe",
TITLE="{NETRJS:} A third level protocol for Remote Job Entry",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=88,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=1971,
ABSTRACT="Description of NETRJS, which is the name for a message
protocol and a set of control conventions which will allow users at
remote Hosts to access the RJS remote batch subsystem of UCLA/CCN.",
URL="http://www.rfc-editor.org/rfc/rfc88.txt"
}

@TECHREPORT{rfc89,
AUTHOR="Robert M. Metcalfe",
TITLE="Some historic moments in networking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=89,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1971,
ABSTRACT="Noteworthy achievements for the MIT-Project MAC Dynamic
Modeling/Computer Graphics PDP-6/10 System, while awaiting the
completion of an interim network control program.",
URL="http://www.rfc-editor.org/rfc/rfc89.txt"
}

@TECHREPORT{rfc90,
AUTHOR="R. Braden",
TITLE="{CCN} as a Network Service Center",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=90,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1971,
ABSTRACT="Discussion of UCLA's Campus Computing Network of services and
implementation priorities.",
URL="http://www.rfc-editor.org/rfc/rfc90.txt"
}

@TECHREPORT{rfc93,
AUTHOR="A. A. McKenzie",
TITLE="Initial Connection Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=93,
PAGES=1,
DAYS=15,
MONTH=jan,
YEAR=1971,
ABSTRACT="A review of the Initial Connection Protocol (ICP), first
described in RFC 66 and restated in RFC 80.",
URL="http://www.rfc-editor.org/rfc/rfc93.txt"
}

@TECHREPORT{rfc94,
AUTHOR="E. Harslem and John F. Heafner",
TITLE="Some thoughts on Network Graphics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=94,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="Discussion of the initial reaction to RFC 86, whose purpose
was to provide a basis for discussion and development of Network
graphics.",
URL="http://www.rfc-editor.org/rfc/rfc94.txt"
}

@TECHREPORT{rfc95,
AUTHOR="S. D. Crocker",
TITLE="Distribution of {NWG/RFC's} through the {NIC}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=95,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="Standards for establishing lines of communication of all of
the sites with the Network Information Center, in regards to
distribution of RFC's.",
URL="http://www.rfc-editor.org/rfc/rfc95.txt"
}

@TECHREPORT{rfc96,
AUTHOR="R. W. Watson",
TITLE="An Interactive Network Experiment to Study Modes of Access the Network
Information Center",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=96,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="Outlines the framework for a simple interactive experiment to
study modes of access to the Network Information Center (NIC).",
URL="http://www.rfc-editor.org/rfc/rfc96.txt"
}

@TECHREPORT{rfc97,
AUTHOR="J. T. Melvin and R. W. Watson",
TITLE="First Cut at a Proposed Telnet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=97,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="This document was motivated by the need to set specifications
for a protocol which would allow on-line access to the Network
Information Center (NIC)."
}

@TECHREPORT{rfc98,
AUTHOR="E. Meyer and T. P. Skinner",
TITLE="Logger Protocol Proposal",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=98,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT={This {"}network logger protocol{"} 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.},
URL="http://www.rfc-editor.org/rfc/rfc98.txt"
}

@TECHREPORT{rfc99,
AUTHOR="P. M. Karp",
TITLE="Network Meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=99,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1971,
ABSTRACT="Announcement of the next meeting of the Network Working Group
for 20 May 1970.",
URL="http://www.rfc-editor.org/rfc/rfc99.txt"
}

@TECHREPORT{rfc264,
AUTHOR="A. K. Bhushan and B. Braden and W. Crowther and E. Harslem and J. Heafner
and A. McKenize and B. Sundberg and D. Watson",
TITLE="The Data Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=264,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="This paper is a revision of RFC 171. The changes to RFC 171
are presented in this document. The protocol is also restated for
additional review.",
URL="http://www.rfc-editor.org/rfc/rfc264.txt"
}

@TECHREPORT{rfc270,
AUTHOR="A. A. McKenzie",
TITLE="Correction to {BBN} Report No.1822 {(NIC} {NO} {7958)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=270,
PAGES=1,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="Updates pages 25 and 26 of BBN report 1822.",
URL="http://www.rfc-editor.org/rfc/rfc270.txt"
}

@TECHREPORT{rfc271,
AUTHOR="B. Cosell",
TITLE="{IMP} System change notifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=271,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="Announcement of a new version of the IMP System, Version 2514.",
URL="http://www.rfc-editor.org/rfc/rfc271.txt"
}

@TECHREPORT{rfc288,
AUTHOR="E. Westheimer",
TITLE="Network host status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=288,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="Updates RFC 287.",
URL="http://www.rfc-editor.org/rfc/rfc288.txt"
}

@TECHREPORT{rfc290,
AUTHOR="A. Mullery",
TITLE="Computer networks and data sharing: A bibliography",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=290,
PAGES=15,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="Updates RFC 243.",
URL="http://www.rfc-editor.org/rfc/rfc290.txt"
}

@TECHREPORT{rfc291,
AUTHOR="D. B. McKay",
TITLE="Data Management Meeting Announcement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=291,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="A meeting about datamanagement will be held February 1972.",
URL="http://www.rfc-editor.org/rfc/rfc291.txt"
}

@TECHREPORT{rfc292,
AUTHOR="J. C. Michener and I. W. Cotton and K. C. Kelley and D. E. Liddle and E.
Meyer",
TITLE="Graphics Protocol: Level 0 only",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=292,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="A description of part of the proposed Network Standard
Graphics Protocol for transmitting graphics data within the ARPA
network. The particular aspects covered are related to the form and
content of graphics information sent from a source of graphical
information to a display package for output to a graphics console.",
URL="http://www.rfc-editor.org/rfc/rfc292.txt"
}

@TECHREPORT{rfc294,
AUTHOR="A. K. Bhushan",
TITLE={The Use of {"}Set Data Type{"} Transaction in File Transfer Protocol},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=294,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="Updates RFC 265.",
URL="http://www.rfc-editor.org/rfc/rfc294.txt"
}

@TECHREPORT{rfc295,
AUTHOR="J. B. Postel",
TITLE="Report of the Protocol Workshop, 12 October 1971",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=295,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="A report on the decisions reached at the protocol workshop
held in conjunction with the NWG meeting of 10 October 1971.",
URL="http://www.rfc-editor.org/rfc/rfc295.txt"
}

@TECHREPORT{rfc296,
AUTHOR="D. E. Liddle",
TITLE="{DS-1} display system",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=296,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="This RFC describes a proposed modular graphic/alphanumeric
display system containing a 512 by 512 line, 60 line per inch plasma
display/memory panel and a minprocessor. It is intended to combine the
advantages of display memory and local processing power in three general
modes."
}

@TECHREPORT{rfc297,
AUTHOR="D. C. Walden",
TITLE="{TIP} Message Buffers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=297,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="Discussion regarding the size of the TIP's message buffers.",
URL="http://www.rfc-editor.org/rfc/rfc297.txt"
}

@TECHREPORT{rfc299,
AUTHOR="D. Hopkin",
TITLE="Information Management System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=299,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1972,
ABSTRACT="Announcement of intent to build an Information Management and
Statistical System for the ILLIAC IV.",
URL="http://www.rfc-editor.org/rfc/rfc299.txt"
}

@TECHREPORT{rfc300,
AUTHOR="J. B. North",
TITLE="{ARPA} Network mailing lists",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=300,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=1972,
ABSTRACT="Obsoletes RFC 211.",
URL="http://www.rfc-editor.org/rfc/rfc300.txt"
}

@TECHREPORT{rfc301,
AUTHOR="R. Alter",
TITLE="{BBN} {IMP} {(#5)} and {NCC} Schedule March {4,} 1971",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=301,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1972,
ABSTRACT="BBN host will be down for a day for moving equipment.",
URL="http://www.rfc-editor.org/rfc/rfc301.txt"
}

@TECHREPORT{rfc302,
AUTHOR="R. F. Bryan",
TITLE="Exercising The {ARPANET}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=302,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1972,
ABSTRACT="Describes a class project to tryout hosts on the ARPANET.",
URL="http://www.rfc-editor.org/rfc/rfc302.txt"
}

@TECHREPORT{rfc304,
AUTHOR="D. B. McKay",
TITLE="Data management system proposal for the {ARPA} network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=304,
DAYS=15,
MONTH=feb,
YEAR=1972,
ABSTRACT="A proposal to provide a framework that will allow the ARPA
community to recognize and develop the necessary tools in a unified
manner enabling the network to manage its resources to the best
advantage of the user."
}

@TECHREPORT{rfc305,
AUTHOR="R. Alter",
TITLE="Unknown Host Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=305,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1972,
ABSTRACT="Discusses testing of IMPs and notes that this may cause some
hosts to receive messages from unregistered addresses.",
URL="http://www.rfc-editor.org/rfc/rfc305.txt"
}

@TECHREPORT{rfc307,
AUTHOR="E. Harslem",
TITLE="Using network Remote Job Entry",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=307,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1972,
ABSTRACT="Announcement of a program on a PDP-10 allowing access to the
Remote Job Service (RJS) at UCLA.",
URL="http://www.rfc-editor.org/rfc/rfc307.txt"
}

@TECHREPORT{rfc308,
AUTHOR="M. Seriff",
TITLE="{ARPANET} host availability data",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=308,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="A SURVEY program is up and working to aid in gathering
information on the availability of various Hosts on the ARPANET.",
URL="http://www.rfc-editor.org/rfc/rfc308.txt"
}

@TECHREPORT{rfc309,
AUTHOR="A. K. Bhushan",
TITLE="Data and File Transfer Workshop Announcement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=309,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="Describes plans for a meeting on FTP to be held April 1972.",
URL="http://www.rfc-editor.org/rfc/rfc309.txt"
}

@TECHREPORT{rfc310,
AUTHOR="A. K. Bhushan",
TITLE="Another Look at Data and File Transfer Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=310,
PAGES=7,
DAYS=15,
MONTH=apr,
YEAR=1972,
ABSTRACT="This paper suggests some specific changes in DTP and FTP that
should make them more useful and/or simplify implementation.",
URL="http://www.rfc-editor.org/rfc/rfc310.txt"
}

@TECHREPORT{rfc311,
AUTHOR="R. F. Bryan",
TITLE="New Console Attachments to the {USCB} Host",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=311,
PAGES=2,
DAYS=15,
MONTH=feb,
YEAR=1972,
ABSTRACT="Describes types of terminals used at UCSB.",
URL="http://www.rfc-editor.org/rfc/rfc311.txt"
}

@TECHREPORT{rfc312,
AUTHOR="A. A. McKenzie",
TITLE="Proposed Change in {IMP-to-Host} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=312,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="This RFC proposes a redefinition of the IMP-to-Host error
message types and the creation of additional IMP-to-Host error message
types. These changes should assist the Hosts in determining appropriate
recovery action without causing any serious reprogramming problems.",
URL="http://www.rfc-editor.org/rfc/rfc312.txt"
}

@TECHREPORT{rfc313,
AUTHOR="T. C. O'Sullivan",
TITLE="Computer based instruction",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=313,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="This paper has two purposes: to solicit comments from the NWG
and others on how selected classes of resources of a General Purpose
Network might be applied to the field of Computer Based Instructions;
and initiate a dialog between interested parties on the problem of
Computer Base Instruction.",
URL="http://www.rfc-editor.org/rfc/rfc313.txt"
}

@TECHREPORT{rfc314,
AUTHOR="I. W. Cotton",
TITLE="Network Graphics Working Group Meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=314,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="Describes plans for a graphics meeting to be held in April
1972.",
URL="http://www.rfc-editor.org/rfc/rfc314.txt"
}

@TECHREPORT{rfc316,
AUTHOR="D. B. McKay and A. Mullery",
TITLE="{ARPA} Network Data Management Working Group",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=316,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1972,
URL="http://www.rfc-editor.org/rfc/rfc316.txt"
}

@TECHREPORT{rfc317,
AUTHOR="J. B. Postel",
TITLE="Official {Host-Host} Protocol Modification: Assigned Link Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=317,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="Lists current Link number assignments. This RFC has been
replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc317.txt"
}

@TECHREPORT{rfc318,
AUTHOR="J. B. Postel",
TITLE="Telnet Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=318,
PAGES=16,
DAYS=15,
MONTH=apr,
YEAR=1972,
ABSTRACT="Obsoletes RFC 158. This Telnet specification was effective for
several years.",
URL="http://www.rfc-editor.org/rfc/rfc318.txt"
}

@TECHREPORT{rfc320,
AUTHOR="R. Reddy",
TITLE="Workshop on Hard Copy Line Printers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=320,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="Announcement of a one day workshop on the XCRIBL system at
CMU."
}

@TECHREPORT{rfc321,
AUTHOR="P. M. Karp",
TITLE="{CBI} Networking Activity at {MITRE}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=321,
PAGES=14,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="Response to RFC 313 - comments on Computer Based Instruction.",
URL="http://www.rfc-editor.org/rfc/rfc321.txt"
}

@TECHREPORT{rfc322,
AUTHOR="V. G. Cerf and J. B. Postel",
TITLE="Well known socket numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=322,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="Announcement of intent to catalog all sockets which are
supposed to be well-known.",
URL="http://www.rfc-editor.org/rfc/rfc322.txt"
}

@TECHREPORT{rfc323,
AUTHOR="V. G. Cerf",
TITLE="Formation of Network Measurement Group {(NMG)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=323,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1972,
ABSTRACT="Describes some network measurement results, some plans for
further measurement and the formation of an interest group.",
URL="http://www.rfc-editor.org/rfc/rfc323.txt"
}

@TECHREPORT{rfc324,
AUTHOR="J. B. Postel",
TITLE="{RJE} Protocol meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=324,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1972,
ABSTRACT="Announcement of a RJE Protocol meeting at UCLA.",
URL="http://www.rfc-editor.org/rfc/rfc324.txt"
}

@TECHREPORT{rfc325,
AUTHOR="G. W. Hicks",
TITLE="Network Remote Job Entry program - {NETRJS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=325,
PAGES=9,
DAYS=15,
MONTH=apr,
YEAR=1972,
ABSTRACT="Report on the NETRJS running at the University of Utah.",
URL="http://www.rfc-editor.org/rfc/rfc325.txt"
}

@TECHREPORT{rfc327,
AUTHOR="A. K. Bhushan",
TITLE="Data and File Transfer workshop notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=327,
PAGES=5,
DAYS=15,
MONTH=apr,
YEAR=1972,
URL="http://www.rfc-editor.org/rfc/rfc327.txt"
}

@TECHREPORT{rfc328,
AUTHOR="J. B. Postel",
TITLE="Suggested Telnet Protocol Changes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=328,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1972,
ABSTRACT="This RFC proposes changes to the Telnet protocol.",
URL="http://www.rfc-editor.org/rfc/rfc328.txt"
}

@TECHREPORT{rfc331,
AUTHOR="J. M. McQuillan",
TITLE="{IMP} System Change Notification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=331,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1972,
ABSTRACT="Announcement of the release of IMPSYS 2600.",
URL="http://www.rfc-editor.org/rfc/rfc331.txt"
}

@TECHREPORT{rfc333,
AUTHOR="R. D. Bressler and D. J. Murphy and D. C. Walden",
TITLE="Proposed experiment with a Message Switching Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=333,
PAGES=26,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="This document attempts to sketch how one would organize the
lowest level host-host protocol in the ARPANET around Message Switching
Protocols (MSPs) and how this organization would affect the
implementation of the host software.",
URL="http://www.rfc-editor.org/rfc/rfc333.txt"
}

@TECHREPORT{rfc334,
AUTHOR="A. A. McKenzie",
TITLE="Network Use on May 8",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=334,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1972,
URL="http://www.rfc-editor.org/rfc/rfc334.txt"
}

@TECHREPORT{rfc335,
AUTHOR="R. F. Bryan",
TITLE="New Interface - {IMP/360}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=335,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="Announcement of a new interface and requests to hear of any
difficulties network users encounter while operating with UCSB.",
URL="http://www.rfc-editor.org/rfc/rfc335.txt"
}

@TECHREPORT{rfc336,
AUTHOR="I. W. Cotton",
TITLE="Level 0 Graphic Input Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=336,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="A description of the graphics input protocol as discussed at a
Network Graphics Working Group meeting.",
URL="http://www.rfc-editor.org/rfc/rfc336.txt"
}

@TECHREPORT{rfc338,
AUTHOR="R. Braden",
TITLE="{EBCDIC/ASCII} Mapping for Network {RJE}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=338,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="This RFC proposes: to make all users of NETRJS aware of the
changed ASCII mapping; to call this problem to the attention of the
Network RJE Protocol committee; and to knowledge and support Joel
Winett's pioneering work in this area.",
URL="http://www.rfc-editor.org/rfc/rfc338.txt"
}

@TECHREPORT{rfc339,
AUTHOR="R. Thomas",
TITLE={{MLTNET:} A {"}Multi Telnet{"} Subsystem for Tenex},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=339,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="This RFC describes MLTNET as a Telnet-like facility for Tenex
which enables a user to control a number of jobs, running on different
ARPANET hosts. MLTNET is currently a subsystem on the BBN-Tenex host.",
URL="http://www.rfc-editor.org/rfc/rfc339.txt"
}

@TECHREPORT{rfc340,
AUTHOR="T. C. O'Sullivan",
TITLE="Proposed Telnet Changes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=340,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="A proposed change to the Telnet protocol calling for one
standard protocol and dropping the idea of minimum implementation.",
URL="http://www.rfc-editor.org/rfc/rfc340.txt"
}

@TECHREPORT{rfc345,
AUTHOR="K. C. Kelley",
TITLE="Interest in Mixed Integer Programming {(MPSX} on {NIC} {360/91} at {CCN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=345,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="Request for interested persons in the MPSX to contact author.",
URL="http://www.rfc-editor.org/rfc/rfc345.txt"
}

@TECHREPORT{rfc346,
AUTHOR="J. B. Postel",
TITLE="Satellite Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=346,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="Discussion on using space satellite transmission links in the
ARPANET.",
URL="http://www.rfc-editor.org/rfc/rfc346.txt"
}

@TECHREPORT{rfc347,
AUTHOR="J. B. Postel",
TITLE="Echo process",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=347,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT={A RFC discussing debugging and measurement puposes for those
hosts which are willing to implement an {"}Echo{"} process. Old version;
see
RFC 862.},
URL="http://www.rfc-editor.org/rfc/rfc347.txt"
}

@TECHREPORT{rfc348,
AUTHOR="J. B. Postel",
TITLE="Discard Process",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=348,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT={A RFC discussing debugging and measurement puposes for those
hosts which are willing to implement a {"}Discard{"} process. Old version;
see RFC 863.},
URL="http://www.rfc-editor.org/rfc/rfc348.txt"
}

@TECHREPORT{rfc349,
AUTHOR="J. B. Postel",
TITLE="Proposed Standard Socket Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=349,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="A proposal to officially standardize socket number
assignments.",
URL="http://www.rfc-editor.org/rfc/rfc349.txt"
}

@TECHREPORT{rfc350,
AUTHOR="R. Stoughton",
TITLE="User Accounts for {UCSB} {On-Line} System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=350,
PAGES=3,
DAYS=15,
MONTH=may,
YEAR=1972,
ABSTRACT="Announcement of new login parameters for the UCSB On-Line
System.",
URL="http://www.rfc-editor.org/rfc/rfc350.txt"
}

@TECHREPORT{rfc351,
AUTHOR="D. H. Crocker",
TITLE="Graphics information form for the {ARPANET} graphics resources notebook",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=351,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1972,
ABSTRACT="A questionnaire about the state of graphics resources at
various sites.",
URL="http://www.rfc-editor.org/rfc/rfc351.txt"
}

@TECHREPORT{rfc352,
AUTHOR="D. H. Crocker",
TITLE="{TIP} Site Information Form",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=352,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1972,
ABSTRACT="An information form to provide additional information for TIP
users of the NET.",
URL="http://www.rfc-editor.org/rfc/rfc352.txt"
}

@TECHREPORT{rfc354,
AUTHOR="A. K. Bhushan",
TITLE="File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=354,
PAGES=25,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="This RFC obsoletes RFCs 264,265. The File Transfer Protocol
(FTP) is a protocol for file transfer between HOSTs on the ARPANET. The
primary function of FTP is to transfer files efficiently and reliably
among hosts and to allow the convenient use of remote file storage
capabilities.",
URL="http://www.rfc-editor.org/rfc/rfc354.txt"
}

@TECHREPORT{rfc355,
AUTHOR="J. Davidson",
TITLE="Response to {NWG/RFC} 346",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=355,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1972,
URL="http://www.rfc-editor.org/rfc/rfc355.txt"
}

@TECHREPORT{rfc356,
AUTHOR="R. Alter",
TITLE="{ARPA} Network Control Center",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=356,
PAGES=1,
DAYS=15,
MONTH=jun,
YEAR=1972,
ABSTRACT="Announcement of the NCC's new operation schedule.",
URL="http://www.rfc-editor.org/rfc/rfc356.txt"
}

@TECHREPORT{rfc357,
AUTHOR="J. Davidson",
TITLE="Echoing strategy for satellite links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=357,
PAGES=13,
DAYS=15,
MONTH=jun,
YEAR=1972,
ABSTRACT="This document describes a strategy which will eliminate the
delay associated with simple echoing and allow the transmission delay to
be hidden in the cost of computation only. This scheme is proposed as an
optional addition to existing User Telnets; its use requires the
explicit support of a cooperating server process.",
URL="http://www.rfc-editor.org/rfc/rfc357.txt"
}

@TECHREPORT{rfc359,
AUTHOR="D. C. Walden",
TITLE="Status of the Release of the New {IMP} System {(2600)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=359,
PAGES=1,
DAYS=15,
MONTH=jun,
YEAR=1972,
ABSTRACT="Obsoletes RFC 343.",
URL="http://www.rfc-editor.org/rfc/rfc359.txt"
}

@TECHREPORT{rfc360,
AUTHOR="C. Holland",
TITLE="Proposed Remote Job Entry Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=360,
DAYS=15,
MONTH=jun,
YEAR=1972,
ABSTRACT="This protocol specifies the Network standard procedures for
remote job entry as a mechanism whereby a user at one location causes a
batch-processing job to be run at some other location."
}

@TECHREPORT{rfc361,
AUTHOR="R. D. Bressler",
TITLE="Deamon Processes on Host 106",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=361,
PAGES=1,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="Deamon Processes on Host 106.",
URL="http://www.rfc-editor.org/rfc/rfc361.txt"
}

@TECHREPORT{rfc364,
AUTHOR="M. D. Abrams",
TITLE="Serving remote users on the {ARPANET}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=364,
PAGES=6,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="This paper asserts that a problem exists in serving remote
users and offers a set of suggestions for its amelioration.",
URL="http://www.rfc-editor.org/rfc/rfc364.txt"
}

@TECHREPORT{rfc365,
AUTHOR="D. C. Walden",
TITLE="Letter to All {TIP} Users",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=365,
PAGES=5,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT={Descriptions of new commands that have recently been added to
the {"}TIP Users Guide{"}.},
URL="http://www.rfc-editor.org/rfc/rfc365.txt"
}

@TECHREPORT{rfc368,
AUTHOR="R. Braden",
TITLE={Comments on {"}Proposed Remote Job Entry Protocol{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=368,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="Suggestions on honing the final standard of the RJE protocol
(references RFC 360).",
URL="http://www.rfc-editor.org/rfc/rfc368.txt"
}

@TECHREPORT{rfc369,
AUTHOR="J. R. Pickens",
TITLE="Evaluation of {ARPANET} services {January-March,} 1972",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=369,
PAGES=11,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="This paper provides descriptions, surveys, critiques of
ARPANET services, and suggestions for improvement.",
URL="http://www.rfc-editor.org/rfc/rfc369.txt"
}

@TECHREPORT{rfc371,
AUTHOR="R. E. Kahn",
TITLE="Demonstration at International Computer Communications Conference",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=371,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="Observation and notes on the ICCC meeting demonstration.",
URL="http://www.rfc-editor.org/rfc/rfc371.txt"
}

@TECHREPORT{rfc372,
AUTHOR="R. W. Watson",
TITLE="Notes on a Conversation with Bob Kahn on the {ICCC}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=372,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="Discussion on some aspects of the ICCC meeting demonstration.",
URL="http://www.rfc-editor.org/rfc/rfc372.txt"
}

@TECHREPORT{rfc373,
AUTHOR="J. McCarthy",
TITLE="Arbitrary Character Sets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=373,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="Suggests how to get arbitrary characters sets stored in
computers and to be able to display them on any CRT screen, edit them
using any keyboard, and print them on any printer.",
URL="http://www.rfc-editor.org/rfc/rfc373.txt"
}

@TECHREPORT{rfc374,
AUTHOR="A. A. McKenzie",
TITLE="{IMP} System Announcement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=374,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="Updates RFCs 331,343,359.",
URL="http://www.rfc-editor.org/rfc/rfc374.txt"
}

@TECHREPORT{rfc377,
AUTHOR="R. Braden",
TITLE="Using {TSO} via {ARPA} Network Virtual Terminal",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=377,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="Announcement of IBM's Time Sharing Option (TSO) availability
at UCLA/CCN on Socket 1, using the standard Telnet protocol.",
URL="http://www.rfc-editor.org/rfc/rfc377.txt"
}

@TECHREPORT{rfc378,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (July {1972)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=378,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="Traffic statistics for the month of July 1972.",
URL="http://www.rfc-editor.org/rfc/rfc378.txt"
}

@TECHREPORT{rfc379,
AUTHOR="R. Braden",
TITLE="Using {TSO} at {CCN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=379,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="Announcement that IBM's Time Sharing Option (TSO) is up on a
regularly scheduled basis at UCLA/CCN.",
URL="http://www.rfc-editor.org/rfc/rfc379.txt"
}

@TECHREPORT{rfc381,
AUTHOR="J. M. McQuillan",
TITLE="Three aids to improved network operation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=381,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1972,
ABSTRACT="Discusses helpful aids to improved network operation:
schedules of software maintenance, IMP-to-Host communication, and
network news service.",
URL="http://www.rfc-editor.org/rfc/rfc381.txt"
}

@TECHREPORT{rfc382,
AUTHOR="L. McDaniel",
TITLE="Mathematical Software on the {ARPA} Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=382,
PAGES=1,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="Comments on the efforts to develop high quality libraries of
mathematical and statistical subroutines.",
URL="http://www.rfc-editor.org/rfc/rfc382.txt"
}

@TECHREPORT{rfc384,
AUTHOR="J. B. North",
TITLE="Official site idents for organizations in the {ARPA} Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=384,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="Includes two lists, a list in alpha order and a list by Site
address. Obsoletes RFC 289.",
URL="http://www.rfc-editor.org/rfc/rfc384.txt"
}

@TECHREPORT{rfc385,
AUTHOR="A. K. Bhushan",
TITLE="Comments on the File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=385,
PAGES=6,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="The comments in this document include errata, further
discussion, emphasis points, and additions to the protocol. Updates RFC
354.",
URL="http://www.rfc-editor.org/rfc/rfc385.txt"
}

@TECHREPORT{rfc386,
AUTHOR="B. Cosell and D. C. Walden",
TITLE="Letter to {TIP} users-2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=386,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="A second point of information letter to TIP users. Updates RFC
365.",
URL="http://www.rfc-editor.org/rfc/rfc386.txt"
}

@TECHREPORT{rfc387,
AUTHOR="K. C. Kelley and J. Meir",
TITLE="Some experiences in implementing Network Graphics Protocol Level 0",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=387,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1972,
URL="http://www.rfc-editor.org/rfc/rfc387.txt"
}

@TECHREPORT{rfc388,
AUTHOR="V. G. Cerf",
TITLE="{NCP} statistics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=388,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="Updates RFC 323. Announcement that UCLA/NMC is prepared to
gather NCP statistics on a daily basis.",
URL="http://www.rfc-editor.org/rfc/rfc388.txt"
}

@TECHREPORT{rfc389,
AUTHOR="B. Noble",
TITLE="{UCLA} Campus Computing Network Liaison Staff for {ARPA} Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=389,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1972,
ABSTRACT="A list for ARPA Network contacts at UCLA/CCN.",
URL="http://www.rfc-editor.org/rfc/rfc389.txt"
}

@TECHREPORT{rfc390,
AUTHOR="R. Braden",
TITLE="{TSO} Scenario",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=390,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1972,
ABSTRACT="An example session with TSO on UCLA-CCN.",
URL="http://www.rfc-editor.org/rfc/rfc390.txt"
}

@TECHREPORT{rfc391,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (August {1972)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=391,
PAGES=3,
DAYS=15,
MONTH=sep,
YEAR=1972,
ABSTRACT="A report on the Host traffic statistics for the month of
August 1972. Updates RFC 378.",
URL="http://www.rfc-editor.org/rfc/rfc391.txt"
}

@TECHREPORT{rfc392,
AUTHOR="G. W. Hicks and B. D. Wessler",
TITLE="Measurement of host costs for transmitting network data",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=392,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1972,
ABSTRACT={Discussion of Utah's development of a program to use the
Remote Job Service System (RJS) at UCLA-CCN in conjunction with Utah's
{"}batch{"} users.},
URL="http://www.rfc-editor.org/rfc/rfc392.txt"
}

@TECHREPORT{rfc393,
AUTHOR="J. M. Winett",
TITLE="Comments on Telnet Protocol Changes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=393,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="Comments and objections to two of the three recent suggestions
for changing the Telnet protocol as described in RFC 328.",
URL="http://www.rfc-editor.org/rfc/rfc393.txt"
}

@TECHREPORT{rfc394,
AUTHOR="J. M. McQuillan",
TITLE="Two Proposed Changes to the {IMP-Host} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=394,
PAGES=3,
DAYS=15,
MONTH=sep,
YEAR=1972,
ABSTRACT="Updates RFC 381. This note describes two changes to the
IMP-Host communication protocol described in BBN Report 1822.",
URL="http://www.rfc-editor.org/rfc/rfc394.txt"
}

@TECHREPORT{rfc395,
AUTHOR="J. M. McQuillan",
TITLE="Switch Settings on {IMPs} and {TIPs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=395,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="Discussion on a description of the switches on the front panel
of IMPs and TIPs that are important to the correct operation of the
network software.",
URL="http://www.rfc-editor.org/rfc/rfc395.txt"
}

@TECHREPORT{rfc396,
AUTHOR="S. Bunch",
TITLE="Network Graphics Working Group Meeting - Second Iteration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=396,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1972,
URL="http://www.rfc-editor.org/rfc/rfc396.txt"
}

@TECHREPORT{rfc398,
AUTHOR="J. R. Pickens and E. Faeh",
TITLE="{ICP} Sockets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=398,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1972,
ABSTRACT="Announcement that users with Tektronix or IMLAC terminals, or
with systems that support the proposed Level 0 graphics protocol can
access UCSB graphics.",
URL="http://www.rfc-editor.org/rfc/rfc398.txt"
}

@TECHREPORT{rfc399,
AUTHOR="M. Krilanovich",
TITLE="{SMFS} Login and Logout",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=399,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1972,
URL="http://www.rfc-editor.org/rfc/rfc399.txt"
}

@TECHREPORT{rfc400,
AUTHOR="A. A. McKenzie",
TITLE="Traffic Statistics (September {1972)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=400,
PAGES=3,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="A report on the Host traffic statistics for the month of
September 1972. Updates RFC 391.",
URL="http://www.rfc-editor.org/rfc/rfc400.txt"
}

@TECHREPORT{rfc401,
AUTHOR="J. E. Hansen",
TITLE="Conversion of {NGP-0} Coordinates to Device Specific Coordinates",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=401,
PAGES=2,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="A means is described to convert NGP coordinates to interger
coordinates in the range zero to M, where M is the maximum address of
the device screen on a machine using 2's complement arithmetic.",
URL="http://www.rfc-editor.org/rfc/rfc401.txt"
}

@TECHREPORT{rfc404,
AUTHOR="A. A. McKenzie",
TITLE="Host Address Changes Involving Rand and {ISI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=404,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="The new address of ISI is IMP 22. THe new address of RAND is
IMP 7.",
URL="http://www.rfc-editor.org/rfc/rfc404.txt"
}

@TECHREPORT{rfc405,
AUTHOR="A. A. McKenzie",
TITLE="Correction to {RFC} 404",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=405,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="Typographical error notation. Obsoletes RFC 404.",
URL="http://www.rfc-editor.org/rfc/rfc405.txt"
}

@TECHREPORT{rfc406,
AUTHOR="J. M. McQuillan",
TITLE="Scheduled {IMP} Software Releases",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=406,
PAGES=2,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="Explains the plans and schedule for IMP software maintenance.",
URL="http://www.rfc-editor.org/rfc/rfc406.txt"
}

@TECHREPORT{rfc407,
AUTHOR="R. D. Bressler and R. Guida and A. A. McKenzie",
TITLE="Remote Job Entry Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=407,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="The release of the official Remote Job Entry Protocol, per the
ARPA office.",
URL="http://www.rfc-editor.org/rfc/rfc407.txt"
}

@TECHREPORT{rfc408,
AUTHOR="A. D. Owen and J. B. Postel",
TITLE="{NETBANK}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=408,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1972,
ABSTRACT="A proposed idea for a protocol (or service) that is offered as
an aid to network use for new users.",
URL="http://www.rfc-editor.org/rfc/rfc408.txt"
}

@TECHREPORT{rfc409,
AUTHOR="J. A. White",
TITLE="Tenex interface to {UCSB's} {Simple-Minded} File System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=409,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="This document is intended to provide users with the
information necessary to use SMFS from a terminal; the reader is assumed
familiar with Tenex.",
URL="http://www.rfc-editor.org/rfc/rfc409.txt"
}

@TECHREPORT{rfc410,
AUTHOR="J. M. McQuillan",
TITLE="Removal of the 30-Second Delay When Hosts Come Up",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=410,
PAGES=2,
DAYS=15,
MONTH=nov,
YEAR=1972,
ABSTRACT="A proposal to elminate the 30-second delay altogether.",
URL="http://www.rfc-editor.org/rfc/rfc410.txt"
}

@TECHREPORT{rfc411,
AUTHOR="M. A. Padlipsky",
TITLE="New {MULTICS} Network Software Features",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=411,
PAGES=2,
DAYS=15,
MONTH=nov,
YEAR=1972,
ABSTRACT="Discussion on two recently-installed features of the Multics
Network software.",
URL="http://www.rfc-editor.org/rfc/rfc411.txt"
}

@TECHREPORT{rfc412,
AUTHOR="G. W. Hicks",
TITLE="User {FTP} Documentation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=412,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1972,
ABSTRACT={A {"}help{"} file for the Utah-10 implementation of the User FTP
process.},
URL="http://www.rfc-editor.org/rfc/rfc412.txt"
}

@TECHREPORT{rfc413,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (October {1972)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=413,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1972,
ABSTRACT="Three sets of network traffic statistic reports. Updates RFC
400.",
URL="http://www.rfc-editor.org/rfc/rfc413.txt"
}

@TECHREPORT{rfc414,
AUTHOR="A. K. Bhushan",
TITLE="File Transfer Protocol {(FTP)} status and further comments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=414,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="A status report on working server and user FTPs.",
URL="http://www.rfc-editor.org/rfc/rfc414.txt"
}

@TECHREPORT{rfc415,
AUTHOR="H. Murray",
TITLE="Tenex bandwidth",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=415,
PAGES=2,
DAYS=15,
MONTH=nov,
YEAR=1972,
ABSTRACT="Considerations of the performances of each host. References
RFC 392.",
URL="http://www.rfc-editor.org/rfc/rfc415.txt"
}

@TECHREPORT{rfc416,
AUTHOR="J. C. Norton",
TITLE="{ARC} System Will Be Unavailable for Use During Thanksgiving Week",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=416,
PAGES=2,
DAYS=15,
MONTH=nov,
YEAR=1972,
ABSTRACT="The SRI-ARC machine will be down for 9-10 days.",
URL="http://www.rfc-editor.org/rfc/rfc416.txt"
}

@TECHREPORT{rfc417,
AUTHOR="J. B. Postel and C. S. Kline",
TITLE="Link usage violation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=417,
PAGES=1,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="The protocol police issue a citation.",
URL="http://www.rfc-editor.org/rfc/rfc417.txt"
}

@TECHREPORT{rfc418,
AUTHOR="W. Hathaway",
TITLE="Server file transfer under {TSS/360} at {NASA} Ames",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=418,
DAYS=15,
MONTH=nov,
YEAR=1972,
ABSTRACT="This RFC is a description of the initial implementation of
Server File Transfer at NASA-Ames Research Center."
}

@TECHREPORT{rfc419,
AUTHOR="A. Vezza",
TITLE="To: Network liaisons and station agents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=419,
PAGES=1,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="The MIT Dynamic Modeling System will be down for 2-4 weeks.",
URL="http://www.rfc-editor.org/rfc/rfc419.txt"
}

@TECHREPORT{rfc421,
AUTHOR="A. A. McKenzie",
TITLE="Software Consulting Service for Network Users",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=421,
DAYS=15,
MONTH=nov,
YEAR=1972,
ABSTRACT="An announcement of a BBN software consulting service that has
been established for ARPA network users.",
URL="http://www.rfc-editor.org/rfc/rfc421.txt"
}

@TECHREPORT{rfc422,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (November {1972)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=422,
PAGES=4,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="Report on the Host traffic statistics for the month of
November 1972. Updates RFC 413.",
URL="http://www.rfc-editor.org/rfc/rfc422.txt"
}

@TECHREPORT{rfc423,
AUTHOR="B. Noble",
TITLE="{UCLA} Campus Computing Network Liaison Staff for {ARPANET}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=423,
PAGES=2,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="A list of ARPA network contacts at CCN. Updates RFC 389.",
URL="http://www.rfc-editor.org/rfc/rfc423.txt"
}

@TECHREPORT{rfc425,
AUTHOR="R. D. Bressler",
TITLE={{"}But my {NCP} costs {$500} a day{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=425,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="Discussion on the cost of network software and network use.",
URL="http://www.rfc-editor.org/rfc/rfc425.txt"
}

@TECHREPORT{rfc429,
AUTHOR="J. B. Postel",
TITLE="Character Generator Process",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=429,
PAGES=1,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="A proposal that there be a standard process implemented on
whatever hosts desire which generates character data with out any regard
to input.",
URL="http://www.rfc-editor.org/rfc/rfc429.txt"
}

@TECHREPORT{rfc431,
AUTHOR="M. Krilanovich",
TITLE="Update on {SMFS} Login and Logout",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=431,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="This document obsoletes RFC 399, which introduced the Login
and Logout commands for UCSB's SMFS, but was incomplete. RFC 399 is
restated more fully in this RFC.",
URL="http://www.rfc-editor.org/rfc/rfc431.txt"
}

@TECHREPORT{rfc432,
AUTHOR="N. Neigus",
TITLE="Network logical map",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=432,
PAGES=1,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="Attachment of the network logical map as of December 30, 1972.",
URL="http://www.rfc-editor.org/rfc/rfc432.txt"
}

@TECHREPORT{rfc433,
AUTHOR="J. B. Postel",
TITLE="Socket number list",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=433,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1972,
ABSTRACT="Establishment of assigned socket numbers to be used for public
functions. This RFC has been replaced by RFC 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc433.txt"
}

@TECHREPORT{rfc403,
AUTHOR="G. W. Hicks",
TITLE="Desirability of a network 1108 service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=403,
DAYS=15,
MONTH=jan,
YEAR=1973
}

@TECHREPORT{rfc420,
AUTHOR="H. Murray",
TITLE="{CCA} {ICCC} weather demo",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=420,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="Announcement that the weather demo for the ICCC show is now
generally available.",
URL="http://www.rfc-editor.org/rfc/rfc420.txt"
}

@TECHREPORT{rfc426,
AUTHOR="R. Thomas",
TITLE="Reconnection Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=426,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="This document describes several situations in which the
ability to reconnect is useful, presents a mechanism to achieve
reconnections, sketches how the mechanism could be added to Host-Host or
Telnet protocol, and recommends a place for the mechanism in the
protocol hierarchy.",
URL="http://www.rfc-editor.org/rfc/rfc426.txt"
}

@TECHREPORT{rfc430,
AUTHOR="R. Braden",
TITLE="Comments on File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=430,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Discusses several issues in FTP.",
URL="http://www.rfc-editor.org/rfc/rfc430.txt"
}

@TECHREPORT{rfc434,
AUTHOR="A. A. McKenzie",
TITLE="{IMP/TIP} memory retrofit schedule",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=434,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="Explains plans and schedule for IMP and TIP upgrades.",
URL="http://www.rfc-editor.org/rfc/rfc434.txt"
}

@TECHREPORT{rfc435,
AUTHOR="B. Cosell and D. C. Walden",
TITLE="Telnet issues",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=435,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="This RFC discusses a number of Telnet related issues, with the
central issue of discussion being echoing.",
URL="http://www.rfc-editor.org/rfc/rfc435.txt"
}

@TECHREPORT{rfc436,
AUTHOR="M. Krilanovich",
TITLE="Announcement of {RJS} at {UCSB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=436,
PAGES=1,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="Announcement of the availability of RJS at UCSB.",
URL="http://www.rfc-editor.org/rfc/rfc436.txt"
}

@TECHREPORT{rfc437,
AUTHOR="E. Faeh",
TITLE="Data Reconfiguration Service at {UCSB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=437,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="Announcement of the availability of the Data Reconfiguration
Service (DRS) at UCSB.",
URL="http://www.rfc-editor.org/rfc/rfc437.txt"
}

@TECHREPORT{rfc438,
AUTHOR="R. Thomas and R. Clements",
TITLE="{FTP} server-server interaction",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=438,
PAGES=3,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="This document suggests a simple extension to FTP which would
allow a FTP user process at one site to arrange for FTP server processes
at other sites to act cooperatively on its behalf.",
URL="http://www.rfc-editor.org/rfc/rfc438.txt"
}

@TECHREPORT{rfc439,
AUTHOR="V. G. Cerf",
TITLE="{PARRY} encounters the {DOCTOR}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=439,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="A lighthearted documentation on a session that actually
happened on September 18, 1972.",
URL="http://www.rfc-editor.org/rfc/rfc439.txt"
}

@TECHREPORT{rfc440,
AUTHOR="D. C. Walden",
TITLE="Scheduled network software maintenance",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=440,
PAGES=1,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="Explains plans and schedule for IMP software maintenance,
expands the normal time slot.",
URL="http://www.rfc-editor.org/rfc/rfc440.txt"
}

@TECHREPORT{rfc441,
AUTHOR="R. D. Bressler and R. Thomas",
TITLE="{Inter-Entity} Communication - an experiment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=441,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="A status report concerning an experiment based on the desire
of users, at their consoles, to converse with one another, and to
receive some debugging assistance.",
URL="http://www.rfc-editor.org/rfc/rfc441.txt"
}

@TECHREPORT{rfc442,
AUTHOR="V. G. Cerf",
TITLE="Current flow-control scheme for {IMPSYS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=442,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="This RFC discusses the current flow-control scheme for IMPSYS.",
URL="http://www.rfc-editor.org/rfc/rfc442.txt"
}

@TECHREPORT{rfc443,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (December {1972)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=443,
PAGES=3,
DAYS=15,
MONTH=jan,
YEAR=1973,
ABSTRACT="Report on the Host traffic statistics for the month of
December 1972. Updates RFC 422.",
URL="http://www.rfc-editor.org/rfc/rfc443.txt"
}

@TECHREPORT{rfc445,
AUTHOR="A. A. McKenzie",
TITLE="{IMP/TIP} preventive maintenance schedule",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=445,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1973,
URL="http://www.rfc-editor.org/rfc/rfc445.txt"
}

@TECHREPORT{rfc446,
AUTHOR="L. P. Deutsch",
TITLE="Proposal to consider a network program resource notebook",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=446,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1973,
URL="http://www.rfc-editor.org/rfc/rfc446.txt"
}

@TECHREPORT{rfc447,
AUTHOR="Alex A. McKenzie",
TITLE="{IMP/TIP} Memory Retrofit Schedule (Revision {1)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=447,
MONTH=jan,
YEAR=1973,
URL="http://www.rfc-editor.org/rfc/rfc447.txt"
}

@TECHREPORT{rfc448,
AUTHOR="R. Braden",
TITLE="Print files in {FTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=448,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="This document reviews the problem of print files.",
URL="http://www.rfc-editor.org/rfc/rfc448.txt"
}

@TECHREPORT{rfc449,
AUTHOR="D. C. Walden",
TITLE="The Current Flow-control Scheme for {IMPSYS.}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=449,
MONTH=jan,
YEAR=1973,
URL="http://www.rfc-editor.org/rfc/rfc449.txt"
}

@TECHREPORT{rfc450,
AUTHOR="M. A. Padlipsky",
TITLE="{MULTICS} sampling timeout change",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=450,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Announcement of better service for experimental users of MIT
Multics.",
URL="http://www.rfc-editor.org/rfc/rfc450.txt"
}

@TECHREPORT{rfc451,
AUTHOR="M. A. Padlipsky",
TITLE="Tentative proposal for a Unified User Level Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=451,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="A suggestion for the idea of a network standard command
language for interactive systems.",
URL="http://www.rfc-editor.org/rfc/rfc451.txt"
}

@TECHREPORT{rfc452,
AUTHOR="J. M. Winett",
TITLE="{TELENET} Command at Host {LL}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=452,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="This RFC documents the use of the Telnet command at Host LL
for uses under the CP/CMS time-sharing system."
}

@TECHREPORT{rfc453,
AUTHOR="M. D. Kudlick",
TITLE="Meeting announcement to discuss a network mail system",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=453,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Plans for a meeting on electronic mail held February 1973. See
RFC 469.",
URL="http://www.rfc-editor.org/rfc/rfc453.txt"
}

@TECHREPORT{rfc454,
AUTHOR="A. A. McKenzie",
TITLE="File Transfer Protocol - meeting announcement and a new proposed document",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=454,
PAGES=35,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="The specification of the File Transfer Protocol and the
announcement of a meeting (March 1973) to discuss it.",
URL="http://www.rfc-editor.org/rfc/rfc454.txt"
}

@TECHREPORT{rfc455,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (January {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=455,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Report on the Host traffic statistics for the month of January
1973. Updates RFC 443.",
URL="http://www.rfc-editor.org/rfc/rfc455.txt"
}

@TECHREPORT{rfc456,
AUTHOR="M. D. Kudlick",
TITLE="Memorandum: Date change of mail meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=456,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Change in the meeting time for the Network Mail meeting
discussed in RFC 453.",
URL="http://www.rfc-editor.org/rfc/rfc456.txt"
}

@TECHREPORT{rfc457,
AUTHOR="D. C. Walden",
TITLE="{TIPUG}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=457,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="How to get updates to the TIP Users Guide.",
URL="http://www.rfc-editor.org/rfc/rfc457.txt"
}

@TECHREPORT{rfc458,
AUTHOR="R. D. Bressler and R. Thomas",
TITLE="Mail retrieval via {FTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=458,
PAGES=2,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Proposal of two new FTP commands called ReaDMailFile and
ReaDMail.",
URL="http://www.rfc-editor.org/rfc/rfc458.txt"
}

@TECHREPORT{rfc459,
AUTHOR="W. Kantrowitz",
TITLE="Network questionnaires",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=459,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Suggests that there is too much or too many different people
trying to gather data from all the other sites.",
URL="http://www.rfc-editor.org/rfc/rfc459.txt"
}

@TECHREPORT{rfc460,
AUTHOR="C. S. Kline",
TITLE="{NCP} survey",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=460,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="This RFC is a first in a series which will request information
on implmentation of host-to-host protocol.",
URL="http://www.rfc-editor.org/rfc/rfc460.txt"
}

@TECHREPORT{rfc461,
AUTHOR="A. A. McKenzie",
TITLE="Telnet Protocol meeting announcement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=461,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Plans for a meeting on Telnet to be held March 1973.",
URL="http://www.rfc-editor.org/rfc/rfc461.txt"
}

@TECHREPORT{rfc462,
AUTHOR="J. Iseli and D. H. Crocker",
TITLE="Responding to user needs",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=462,
PAGES=2,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="A proposal to have network documentation maintained at the
source, that is, by each site, and available as a distributed database.",
URL="http://www.rfc-editor.org/rfc/rfc462.txt"
}

@TECHREPORT{rfc463,
AUTHOR="A. K. Bhushan",
TITLE="{FTP} comments and response to {RFC} 430",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=463,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="This RFC represents the author's response to RFC 430 and other
similar views.",
URL="http://www.rfc-editor.org/rfc/rfc463.txt"
}

@TECHREPORT{rfc464,
AUTHOR="M. D. Kudlick",
TITLE="Resource notebook framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=464,
PAGES=2,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT={This document presents a framework for coordinating all the
surveys and data gathering efforts concerned with {"}resource notebook{"}
type of information.},
URL="http://www.rfc-editor.org/rfc/rfc464.txt"
}

@TECHREPORT{rfc466,
AUTHOR="J. M. Winett",
TITLE="Telnet logger/server for host {LL-67}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=466,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="This RFC contains writeup documents on the Telnet
Logger/Server for the CP/CMS system on the Lincoln Laboratory 360/67.",
URL="http://www.rfc-editor.org/rfc/rfc466.txt"
}

@TECHREPORT{rfc467,
AUTHOR="Jerry Burchfiel and Raymond Tomlinson",
TITLE="Proposed change to {Host-Host} Protocol: Resynchronization of connection
status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=467,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="To achieve resynchronization of allocation, this RFC proposes
the addition of two commands to the host-host protocol.",
URL="http://www.rfc-editor.org/rfc/rfc467.txt"
}

@TECHREPORT{rfc468,
AUTHOR="R. Braden",
TITLE="{FTP} data compression",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=468,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT={This RFC describes the definition of the {"}HASP{"} or compressed
mode.},
URL="http://www.rfc-editor.org/rfc/rfc468.txt"
}

@TECHREPORT{rfc469,
AUTHOR="M. D. Kudlick",
TITLE="Network mail meeting summary",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=469,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="A description of a meeting on mail held February 1973.",
URL="http://www.rfc-editor.org/rfc/rfc469.txt"
}

@TECHREPORT{rfc470,
AUTHOR="R. Thomas",
TITLE="Change in socket for {TIP} news facility",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=470,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1973,
URL="http://www.rfc-editor.org/rfc/rfc470.txt"
}

@TECHREPORT{rfc471,
AUTHOR="R. Thomas",
TITLE="Workshop on multi-site executive programs",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=471,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="A suggestion for a workshop and a query for interest.",
URL="http://www.rfc-editor.org/rfc/rfc471.txt"
}

@TECHREPORT{rfc472,
AUTHOR="S. Bunch",
TITLE="Illinois' reply to Maxwell's request for graphics information {(NIC}
{14925)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=472,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="This RFC represents the author's response to NIC document
14925.",
URL="http://www.rfc-editor.org/rfc/rfc472.txt"
}

@TECHREPORT{rfc473,
AUTHOR="D. C. Walden",
TITLE="{MIX} and {MIXAL?}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=473,
PAGES=1,
DAYS=15,
MONTH=feb,
YEAR=1973,
URL="http://www.rfc-editor.org/rfc/rfc473.txt"
}

@TECHREPORT{rfc474,
AUTHOR="S. Bunch",
TITLE="Announcement of {NGWG} meeting: Call for papers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=474,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="Plans for a graphics meeting to be held in May 1973.",
URL="http://www.rfc-editor.org/rfc/rfc474.txt"
}

@TECHREPORT{rfc475,
AUTHOR="A. K. Bhushan",
TITLE="{FTP} and network mail system",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=475,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="This paper describes the author's understanding of the results
of the Network Mail System meeting and the implications for FTP."
}

@TECHREPORT{rfc476,
AUTHOR="A. A. McKenzie",
TITLE="{IMP/TIP} memory retrofit schedule (rev {2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=476,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="Describes plans and schedule for upgrading IMPs and TIPs.",
URL="http://www.rfc-editor.org/rfc/rfc476.txt"
}

@TECHREPORT{rfc477,
AUTHOR="M. Krilanovich",
TITLE="Remote Job Service at {UCSB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=477,
PAGES=19,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="This RFC is the follow-on document to RFC 436. This document
restates the essence of the official RJE Protocol and documents in
detail UCSB's implementation of it. Obsoletes RFC 436.",
URL="http://www.rfc-editor.org/rfc/rfc477.txt"
}

@TECHREPORT{rfc478,
AUTHOR="R. D. Bressler and R. Thomas",
TITLE="{FTP} server-server interaction - {II}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=478,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="Discusses server-server interaction where, in a typical
situation, a user conversing with two servers is interested in
retrieving a file from one site and sending it to another.",
URL="http://www.rfc-editor.org/rfc/rfc478.txt"
}

@TECHREPORT{rfc479,
AUTHOR="J. A. White",
TITLE="Use of {FTP} by the {NIC} Journal",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=479,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="This RFC states how the NIC outlined its requirements for
implementing FTP Journal delivery and submission.",
URL="http://www.rfc-editor.org/rfc/rfc479.txt"
}

@TECHREPORT{rfc480,
AUTHOR="J. A. White",
TITLE="Host-dependent {FTP} parameters",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=480,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="This memo is in response to RFC 430.",
URL="http://www.rfc-editor.org/rfc/rfc480.txt"
}

@TECHREPORT{rfc482,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (February {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=482,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of
February 1973. Updates RFC 455.",
URL="http://www.rfc-editor.org/rfc/rfc482.txt"
}

@TECHREPORT{rfc483,
AUTHOR="M. D. Kudlick",
TITLE="Cancellation of the resource notebook framework meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=483,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1973,
URL="http://www.rfc-editor.org/rfc/rfc483.txt"
}

@TECHREPORT{rfc485,
AUTHOR="J. R. Pickens",
TITLE="{MIX} and {MIXAL} at {UCSB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=485,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="A response to Walden's MIX query (RFC 473).",
URL="http://www.rfc-editor.org/rfc/rfc485.txt"
}

@TECHREPORT{rfc486,
AUTHOR="R. D. Bressler",
TITLE="Data transfer revisited",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=486,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="A proposeal to base RJE and FTP on a common data transfer
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc486.txt"
}

@TECHREPORT{rfc487,
AUTHOR="R. D. Bressler",
TITLE="Free file transfer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=487,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="This memo is in response to RFC 430.",
URL="http://www.rfc-editor.org/rfc/rfc487.txt"
}

@TECHREPORT{rfc488,
AUTHOR="M. F. Auerbach",
TITLE="{NLS} classes at network sites",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=488,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="This RFC solicits comments from the Network community on the
desirability of doing on-site classes.",
URL="http://www.rfc-editor.org/rfc/rfc488.txt"
}

@TECHREPORT{rfc489,
AUTHOR="J. B. Postel",
TITLE="Comment on resynchronization of connection status proposal",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=489,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="Comments on ideas proposed in RFC 467.",
URL="http://www.rfc-editor.org/rfc/rfc489.txt"
}

@TECHREPORT{rfc490,
AUTHOR="J. R. Pickens",
TITLE="Surrogate {RJS} for {UCLA-CCN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=490,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1973,
ABSTRACT="A description of how UCLA's RJS can be accessed from UCSB's
standard remote job entry service.",
URL="http://www.rfc-editor.org/rfc/rfc490.txt"
}

@TECHREPORT{rfc491,
AUTHOR="M. A. Padlipsky",
TITLE={What is {"}Free{"}?},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=491,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="This memo discusses the assertion that network mail should be
free; i.e., no login or USER command should be required.",
URL="http://www.rfc-editor.org/rfc/rfc491.txt"
}

@TECHREPORT{rfc492,
AUTHOR="E. Meyer",
TITLE="Response to {RFC} 467",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=492,
PAGES=7,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="This document briefly describes the problems and proposed
solutions, offers comments and alternative suggestions in response to
RFC 467.",
URL="http://www.rfc-editor.org/rfc/rfc492.txt"
}

@TECHREPORT{rfc493,
AUTHOR="J. C. Michener and I. W. Cotton and K. C. Kelley and D. E. Liddle and E.
Meyer",
TITLE="Graphics Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=493,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="Discuses the opinions and decisions reached at the second
meeting of the Network Graphics Group."
}

@TECHREPORT{rfc494,
AUTHOR="D. C. Walden",
TITLE="Availability of {MIX} and {MIXAL} in the Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=494,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="A list of hosts that support programming in MIX and MIXAL.",
URL="http://www.rfc-editor.org/rfc/rfc494.txt"
}

@TECHREPORT{rfc495,
AUTHOR="A. A. McKenzie",
TITLE="Telnet Protocol specifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=495,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="Results of an open meeting discussing Telnet, with two
attached documents which report the results of that meeting.",
URL="http://www.rfc-editor.org/rfc/rfc495.txt"
}

@TECHREPORT{rfc496,
AUTHOR="M. F. Auerbach",
TITLE="{TNLS} quick reference card is available",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=496,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="Announcement of a new TNLS Quick Reference Card.",
URL="http://www.rfc-editor.org/rfc/rfc496.txt"
}

@TECHREPORT{rfc497,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (March {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=497,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of March
1973. Updates RFC 482."
}

@TECHREPORT{rfc498,
AUTHOR="R. Braden",
TITLE="On mail service to {CCN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=498,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="A description of the electronic mail service at UCLA-CCN.",
URL="http://www.rfc-editor.org/rfc/rfc498.txt"
}

@TECHREPORT{rfc499,
AUTHOR="B. R. Reussow",
TITLE="Harvard's network {RJE}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=499,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="A description of the remote job entry service at Harvard.",
URL="http://www.rfc-editor.org/rfc/rfc499.txt"
}

@TECHREPORT{rfc500,
AUTHOR="A. Shoshani and I. Spiegler",
TITLE="Integration of data management systems on a computer network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=500,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="In this paper, discussion is focused on an approach to
integrating data management systems on a computer network for the
purpose of data sharing."
}

@TECHREPORT{rfc501,
AUTHOR="K. T. Pogran",
TITLE={Un-muddling {"}free file transfer{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=501,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="This memo is in response to RFC 487.",
URL="http://www.rfc-editor.org/rfc/rfc501.txt"
}

@TECHREPORT{rfc503,
AUTHOR="N. Neigus and J. B. Postel",
TITLE="Socket number list",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=503,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc503.txt"
}

@TECHREPORT{rfc504,
AUTHOR="R. Thomas",
TITLE="Distributed resources workshop announcement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=504,
PAGES=5,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="Detailed plans for a workshop on Automated Resource Sharing to
be held May 1973.",
URL="http://www.rfc-editor.org/rfc/rfc504.txt"
}

@TECHREPORT{rfc505,
AUTHOR="M. A. Padlipsky",
TITLE="Two solutions to a file transfer access problem",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=505,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="This memo is in response to RFCs 487 and 501.",
URL="http://www.rfc-editor.org/rfc/rfc505.txt"
}

@TECHREPORT{rfc506,
AUTHOR="M. A. Padlipsky",
TITLE="{FTP} command naming problem",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=506,
PAGES=1,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="This RFC discusses a problem when using the File Transfer
Protocol: the choice of names for two crucial commands is faulty.",
URL="http://www.rfc-editor.org/rfc/rfc506.txt"
}

@TECHREPORT{rfc508,
AUTHOR="L. Pfeifer and J. McAfee",
TITLE="Real-time data transmission on the {ARPANET}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=508,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="Discussion on the pros and cons of support of real-time
processes on the ARPA Network.",
URL="http://www.rfc-editor.org/rfc/rfc508.txt"
}

@TECHREPORT{rfc509,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (April {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=509,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of April
1973. Updates RFC 497.",
URL="http://www.rfc-editor.org/rfc/rfc509.txt"
}

@TECHREPORT{rfc510,
AUTHOR="J. A. White",
TITLE="Request for network mailbox addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=510,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="Announcement of Network Journal delivery by the NIC and a
request for updated/additional network mailbox addresses.",
URL="http://www.rfc-editor.org/rfc/rfc510.txt"
}

@TECHREPORT{rfc511,
AUTHOR="J. B. North",
TITLE="Enterprise phone service to {NIC} from {ARPANET} sites",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=511,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="Discussion of cost and alternatives for special telephone
numbers for the NIC.",
URL="http://www.rfc-editor.org/rfc/rfc511.txt"
}

@TECHREPORT{rfc512,
AUTHOR="W. Hathaway",
TITLE="More on lost message detection",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=512,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="This RFC is replaced by RFC 534.",
URL="http://www.rfc-editor.org/rfc/rfc512.txt"
}

@TECHREPORT{rfc513,
AUTHOR="W. Hathaway",
TITLE="Comments on the new Telnet specifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=513,
PAGES=3,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="Discussion of the Telnet Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc513.txt"
}

@TECHREPORT{rfc514,
AUTHOR="W. Kantrowitz",
TITLE="Network make-work",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=514,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="Updates RFC 459.",
URL="http://www.rfc-editor.org/rfc/rfc514.txt"
}

@TECHREPORT{rfc515,
AUTHOR="R. Winter",
TITLE="Specifications for datalanguage: Version {0/9}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=515,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="This specification for Datalanguage is extremely primitive.
Version 0/9 is currently running at CCA and offers an opportunity for
experience with the Datacomputer and with fundamental Datalanguage
concepts."
}

@TECHREPORT{rfc516,
AUTHOR="D. C. Walden",
TITLE="Lost message detection",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=516,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="This RFC is replaced by RFC 534.",
URL="http://www.rfc-editor.org/rfc/rfc516.txt"
}

@TECHREPORT{rfc518,
AUTHOR="N. Vaughan and Elizabeth J. Feinler",
TITLE="{ARPANET} accounts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=518,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="A memo on information regarding opening an account at a given
site on the ARPANET.",
URL="http://www.rfc-editor.org/rfc/rfc518.txt"
}

@TECHREPORT{rfc519,
AUTHOR="J. R. Pickens",
TITLE="Resource evaluation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=519,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="UCSB announces a new test group based upon RFC 369, which
attempts to take a detailed look at specific network resources and
develop initial site dependent and function dependent MINIMAN's."
}

@TECHREPORT{rfc520,
AUTHOR="John Day",
TITLE="Memo to {FTP} group: Proposal for File Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=520,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="This document discusses the File Access Protocol as an
extension to FTP.",
URL="http://www.rfc-editor.org/rfc/rfc520.txt"
}

@TECHREPORT{rfc521,
AUTHOR="A. A. McKenzie",
TITLE="Restricted use of {IMP} {DDT}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=521,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="Proposal of restricted use of IMP DDT due to opinions from
representatives of several sites feeling that uncontrolled use of IMP
DDT made access control mechanisms too vulnerable to interception or
tampering.",
URL="http://www.rfc-editor.org/rfc/rfc521.txt"
}

@TECHREPORT{rfc522,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (May {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=522,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of May
1973. Updates RFC 509."
}

@TECHREPORT{rfc523,
AUTHOR="A. K. Bhushan",
TITLE="{SURVEY} is in operation again",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=523,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="The purpose of this RFC is to alert the network community that
the survey program at MIT-DMCG computer system is in operation.",
URL="http://www.rfc-editor.org/rfc/rfc523.txt"
}

@TECHREPORT{rfc524,
AUTHOR="J. A. White",
TITLE="Proposed Mail Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=524,
PAGES=40,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="A proposed specification for handling mail in the ARPA
network.",
URL="http://www.rfc-editor.org/rfc/rfc524.txt"
}

@TECHREPORT{rfc525,
AUTHOR="W. Parrish and J. R. Pickens",
TITLE="{MIT-MATHLAB} meets {UCSB-OLS} -an example of resource sharing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=525,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="A description of problem solving using both the MIT-P1ACSYM
system and the UCSB-OLS system.",
URL="http://www.rfc-editor.org/rfc/rfc525.txt"
}

@TECHREPORT{rfc526,
AUTHOR="W. K. Pratt",
TITLE="Technical meeting: Digital image processing software systems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=526,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="Announcement of a technical meeting on digital image
processing software systems.",
URL="http://www.rfc-editor.org/rfc/rfc526.txt"
}

@TECHREPORT{rfc527,
AUTHOR="R. Merryman",
TITLE="{ARPAWOCKY}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=527,
DAYS=15,
MONTH=may,
YEAR=1973,
ABSTRACT="A parody by D. L. Covill of the ARPANET based on the
Jabberwocky of Lewis Carroll",
URL="http://www.rfc-editor.org/rfc/rfc527.txt"
}

@TECHREPORT{rfc528,
AUTHOR="J. M. McQuillan",
TITLE="Software checksumming in the {IMP} and network reliability",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=528,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="A description of some of the modifications that have recently
been made to the IMP and TIP programs.",
URL="http://www.rfc-editor.org/rfc/rfc528.txt"
}

@TECHREPORT{rfc529,
AUTHOR="A. A. McKenzie and R. Thomas and Raymond Tomlinson and K. T. Pogran",
TITLE="Note on protocol synch sequences",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=529,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="A response to RFC 513.",
URL="http://www.rfc-editor.org/rfc/rfc529.txt"
}

@TECHREPORT{rfc530,
AUTHOR="A. K. Bhushan",
TITLE="Report on the Survey project",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=530,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="The purpose of this paper is 1) to report on the status of the
SURVEY project and current data, 2) to inform the ARPANET community of
the services offered related to this project, 3) to report on future
plans, and 4) to ask for suggestions and improvements."
}

@TECHREPORT{rfc531,
AUTHOR="M. A. Padlipsky",
TITLE="Feast or famine? A response to two recent {RFC's} about network information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=531,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="This memo is in response to RFCs 514 and 519.",
URL="http://www.rfc-editor.org/rfc/rfc531.txt"
}

@TECHREPORT{rfc532,
AUTHOR="R. Merryman",
TITLE="{UCSD-CC} {Server-FTP} facility",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=532,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="A description of the FTP service at UCSD.",
URL="http://www.rfc-editor.org/rfc/rfc532.txt"
}

@TECHREPORT{rfc533,
AUTHOR="D. C. Walden",
TITLE="{Message-ID} numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=533,
PAGES=1,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="Notice that the ARPANET link field of 8-bits has been expanded
to 12-bits and renamed the message-id field.",
URL="http://www.rfc-editor.org/rfc/rfc533.txt"
}

@TECHREPORT{rfc535,
AUTHOR="R. Thomas",
TITLE="Comments on File Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=535,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="This memo is in response to RFC 420."
}

@TECHREPORT{rfc537,
AUTHOR="S. Bunch",
TITLE="Announcement of {NGG} meeting July {16-17}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=537,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1973,
ABSTRACT="Arrangement details for a graphics meeting held July 1973. See
RFC 549.",
URL="http://www.rfc-editor.org/rfc/rfc537.txt"
}

@TECHREPORT{rfc538,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (June {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=538,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of June
1973. Updates RFC 522.",
URL="http://www.rfc-editor.org/rfc/rfc538.txt"
}

@TECHREPORT{rfc539,
AUTHOR="D. H. Crocker and J. B. Postel",
TITLE="Thoughts on the mail protocol proposed in {RFC} 524",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=539,
PAGES=3,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="This memo is in response to RFC 524. In general, the authors
of this RFC feel that the protocol is extremely rich. They also feel
that there are some minor and some major problems.",
URL="http://www.rfc-editor.org/rfc/rfc539.txt"
}

@TECHREPORT{rfc542,
AUTHOR="N. Neigus",
TITLE="File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=542,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT={This RFC states that there are considerable changes from the
last {"}official{"} version of FTP, but the gross structure still remains
the same. References RFCs 354, 454, and 495.},
URL="http://www.rfc-editor.org/rfc/rfc542.txt"
}

@TECHREPORT{rfc543,
AUTHOR="N. D. Meyer",
TITLE="Network journal submission and delivery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=543,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="Announcement that the first implementation of a Network
Journal Submission and Delivery system is now experimentally up.",
URL="http://www.rfc-editor.org/rfc/rfc543.txt"
}

@TECHREPORT{rfc544,
AUTHOR="N. D. Meyer and K. C. Kelley",
TITLE="Locating on-line documentation at {SRI-ARC}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=544,
PAGES=1,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="Updated memo on how to access on-line documentation at the
NIC.",
URL="http://www.rfc-editor.org/rfc/rfc544.txt"
}

@TECHREPORT{rfc545,
AUTHOR="J. R. Pickens",
TITLE="Of what quality be the {UCSB} resources evaluators?",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=545,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="This memo is in response to RFC 531.",
URL="http://www.rfc-editor.org/rfc/rfc545.txt"
}

@TECHREPORT{rfc546,
AUTHOR="R. Thomas",
TITLE="Tenex load averages for July 1973",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=546,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="Report on the load on two of the key service computers on the
ARPANET.",
URL="http://www.rfc-editor.org/rfc/rfc546.txt"
}

@TECHREPORT{rfc547,
AUTHOR="D. C. Walden",
TITLE="Change to the Very Distant Host specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=547,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="A document on a new version of figure F-4 for BBN Report 1822.",
URL="http://www.rfc-editor.org/rfc/rfc547.txt"
}

@TECHREPORT{rfc548,
AUTHOR="D. C. Walden",
TITLE="Hosts using the {IMP} Going Down message",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=548,
PAGES=1,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT={Discusses the user and intention of the ARPANET IMP's {"}going
down{"} message.},
URL="http://www.rfc-editor.org/rfc/rfc548.txt"
}

@TECHREPORT{rfc549,
AUTHOR="J. C. Michener",
TITLE="Minutes of Network Graphics Group meeting, {15-17} July 1973",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=549,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="Description of a meeting on graphics held in July 1973.",
URL="http://www.rfc-editor.org/rfc/rfc549.txt"
}

@TECHREPORT{rfc550,
AUTHOR="L. P. Deutsch",
TITLE="{NIC} {NCP} experiment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=550,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="Statistics on total incoming messages, incoming host-host
control opcodes, and size of outgoing messages.",
URL="http://www.rfc-editor.org/rfc/rfc550.txt"
}

@TECHREPORT{rfc552,
AUTHOR="A. D. Owen",
TITLE="Single access to standard protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=552,
PAGES=1,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="Queries and statements regarding a socket number assignment
for a single access protocol before the proposed mail protocol becomes
official.",
URL="http://www.rfc-editor.org/rfc/rfc552.txt"
}

@TECHREPORT{rfc553,
AUTHOR="C. Irby and K. Victor",
TITLE="Draft design for a text/graphics protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=553,
PAGES=19,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="This document was proposed as a synthesis of existing ideas
rather than an attempt to put forth new ones. It draws upon the concerns
about the lack of text-handling capabilities of the protoocl suggested
in RFC 493.",
URL="http://www.rfc-editor.org/rfc/rfc553.txt"
}

@TECHREPORT{rfc555,
AUTHOR="J. A. White",
TITLE="Responses to critiques of the proposed mail protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=555,
PAGES=11,
DAYS=15,
MONTH=jul,
YEAR=1973,
ABSTRACT="Response to the proposal for a Mail Protocol (RFC 524).",
URL="http://www.rfc-editor.org/rfc/rfc555.txt"
}

@TECHREPORT{rfc556,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (July {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=556,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of July
1973. Updates RFC 538."
}

@TECHREPORT{rfc557,
AUTHOR="B. D. Wessler",
TITLE="Revelations in network host measurements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=557,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="A report to the RFC community on the current network host
measurements."
}

@TECHREPORT{rfc559,
AUTHOR="A. K. Bushan",
TITLE="Comments on The New Telnet Protocol and its Implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=559,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="This RFC describes the experience that MIT-DM had with the
implementation of the new Telnet protocol (both server and user).",
URL="http://www.rfc-editor.org/rfc/rfc559.txt"
}

@TECHREPORT{rfc560,
AUTHOR="D. H. Crocker and J. B. Postel",
TITLE="Remote Controlled Transmission and Echoing Telnet option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=560,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="Defines a Telnet option for detailed control of echoing to
promote interactive use on long delay paths."
}

@TECHREPORT{rfc561,
AUTHOR="A. K. Bhushan and K. T. Pogran and Raymond Tomlinson and J. A. White",
TITLE="Standardizing Network Mail Headers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=561,
DAYS=15,
MONTH=sep,
YEAR=1973,
ABSTRACT="A proposed document for the explicit specification of such
header information as author, title, and date within the current FTP
mail protocol.",
URL="http://www.rfc-editor.org/rfc/rfc561.txt"
}

@TECHREPORT{rfc562,
AUTHOR="A. A. McKenzie",
TITLE="Modifications to the Telnet specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=562,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="Presenting two documents that update RFC 495, plus summarizing
the changes."
}

@TECHREPORT{rfc563,
AUTHOR="J. Davidson",
TITLE="Comments on the {RCTE} Telnet option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=563,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="A critique based on inferences drawn from the sample Tenex
interaction in RFC 560.",
URL="http://www.rfc-editor.org/rfc/rfc563.txt"
}

@TECHREPORT{rfc565,
AUTHOR="D. G. Cantor",
TITLE="Storing network survey data at the datacomputer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=565,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1973,
ABSTRACT="A project summary report describing the programs developed and
implemented that have been operating successfully with the datacomputer
since July 10.",
URL="http://www.rfc-editor.org/rfc/rfc565.txt"
}

@TECHREPORT{rfc566,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (August {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=566,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of
August 1973. Updates RFC 556.",
URL="http://www.rfc-editor.org/rfc/rfc566.txt"
}

@TECHREPORT{rfc567,
AUTHOR="L. P. Deutsch",
TITLE="Cross Country Network Bandwidth",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=567,
DAYS=15,
MONTH=sep,
YEAR=1973,
ABSTRACT="Computation of cross-country network bandwidth.",
URL="http://www.rfc-editor.org/rfc/rfc567.txt"
}

@TECHREPORT{rfc568,
AUTHOR="J. M. McQuillan",
TITLE="Response to {RFC} 567 - cross country network bandwidth",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=568,
DAYS=15,
MONTH=sep,
YEAR=1973,
ABSTRACT="This RFC serves as a brief correction to several fundamental
errors in RFC 567.",
URL="http://www.rfc-editor.org/rfc/rfc568.txt"
}

@TECHREPORT{rfc569,
AUTHOR="M. A. Padlipsky",
TITLE="{NETED:} A Common Editor for the {ARPA} Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=569,
DAYS=15,
MONTH=oct,
YEAR=1973,
ABSTRACT="Defines a simple line style text editor and suggests that it
be made available on every host in the network.",
URL="http://www.rfc-editor.org/rfc/rfc569.txt"
}

@TECHREPORT{rfc570,
AUTHOR="J. R. Pickens",
TITLE="Experimental input mapping between {NVT} {ASCII} and {UCSB} On Line System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=570,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1973,
ABSTRACT="This RFC updates RFC 216. This document describes the proposed
solutions from the requests to improve the human interface to the UCSB
On-Line System.",
URL="http://www.rfc-editor.org/rfc/rfc570.txt"
}

@TECHREPORT{rfc571,
AUTHOR="R. Braden",
TITLE="Tenex {FTP} problem",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=571,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="A report on a problem in the current Tenex implementation
which is likely to cause incorrect results when transferring files to a
non-Tenex site."
}

@TECHREPORT{rfc573,
AUTHOR="A. K. Bhushan",
TITLE="Data and file transfer: Some measurement results",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=573,
DAYS=15,
MONTH=sep,
YEAR=1973,
ABSTRACT="A report on the results of the performance of MIT-DM's
FTP-user and FTP-server programs."
}

@TECHREPORT{rfc574,
AUTHOR="M. Krilanovich",
TITLE="Announcement of a mail facility at {UCSB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=574,
DAYS=15,
MONTH=sep,
YEAR=1973,
ABSTRACT="An announcement of a server program which supports that subset
of the File Transfer Protocol necessary for mail delivery."
}

@TECHREPORT{rfc576,
AUTHOR="K. Victor",
TITLE="Proposal for modifying linking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=576,
DAYS=15,
MONTH=sep,
YEAR=1973,
ABSTRACT="This RFC presents a plan to modify the link jsys in Tenex to
work in a better way in terms of the user interface."
}

@TECHREPORT{rfc577,
AUTHOR="D. H. Crocker",
TITLE="Mail priority",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=577,
DAYS=15,
MONTH=oct,
YEAR=1973,
ABSTRACT="A paper that suggests interpretations for urgency values,
based on arguments presented in RFC 555. References RFC 539."
}

@TECHREPORT{rfc578,
AUTHOR="A. K. Bhushan and N. D. Ryan",
TITLE="Using {MIT-Mathlab} {MACSYMA} from {MIT-DMS} Muddle",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=578,
DAYS=15,
MONTH=oct,
YEAR=1973,
ABSTRACT="This paper describes an experiment in non-trivial automated
resource sharing between dissimilar systems. The goal of this experiment
was to interface the Muddle system at MIT-DMS to the MACSYMA system at
MIT-Mathlab."
}

@TECHREPORT{rfc579,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (September {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=579,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of
September 1973. Updates RFC 566."
}

@TECHREPORT{rfc580,
AUTHOR="J. B. Postel",
TITLE="Note to Protocol Designers and Implementers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=580,
DAYS=15,
MONTH=oct,
YEAR=1973,
ABSTRACT="An announcement that future proposed protocols shall be
submitted in the form of on-line documents, preferably in NLS files, to
the Network Information Center.",
URL="http://www.rfc-editor.org/rfc/rfc580.txt"
}

@TECHREPORT{rfc581,
AUTHOR="D. H. Crocker and J. B. Postel",
TITLE="Corrections to {RFC} {560:} Remote Controlled Transmission and Echoing
Telnet Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=581,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="This RFC contains corrections to RFC 560, which described the
Remote Controlled Transmission and Echoing Telnet Option."
}

@TECHREPORT{rfc582,
AUTHOR="R. Clements",
TITLE="Comments on {RFC} {580:} Machine readable protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=582,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT={Cites objections to the phrase {"}preferably NLS files{"}.},
URL="http://www.rfc-editor.org/rfc/rfc582.txt"
}

@TECHREPORT{rfc584,
AUTHOR="J. Iseli and D. H. Crocker and N. Neigus",
TITLE="Charter for {ARPANET} Users Interest Working Group",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=584,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="Describes the background, membership, and scope of the newly
formed Users Interest Working Group.",
URL="http://www.rfc-editor.org/rfc/rfc584.txt"
}

@TECHREPORT{rfc585,
AUTHOR="D. H. Crocker and N. Neigus and Elizabeth J. Feinler and J. Iseli",
TITLE="{ARPANET} users interest working group meeting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=585,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="Meeting notes of the first Users Interest Working Group.",
URL="http://www.rfc-editor.org/rfc/rfc585.txt"
}

@TECHREPORT{rfc586,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (October {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=586,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="A report on the Host traffic statistics for the month of
October 1973. Updates RFC 579."
}

@TECHREPORT{rfc587,
AUTHOR="J. B. Postel",
TITLE="Announcing new Telnet options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=587,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="Announcement of Negotiate About Output Line Width (NAOL), and
Negotiate About Output Page Size (NAOP)."
}

@TECHREPORT{rfc588,
AUTHOR="A. Stokes",
TITLE="London node is now up",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=588,
DAYS=15,
MONTH=oct,
YEAR=1973,
ABSTRACT="Notice that an ARPANET node is operational at University
College, London."
}

@TECHREPORT{rfc589,
AUTHOR="R. Braden",
TITLE="{CCN} {NETRJS} server messages to remote user",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=589,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="Describes the system to user messages at UCLA-CCN's remote job
entry service.",
URL="http://www.rfc-editor.org/rfc/rfc589.txt"
}

@TECHREPORT{rfc590,
AUTHOR="M. A. Padlipsky",
TITLE="{MULTICS} address change",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=590,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="Announcement of a plan to change the address of MIT Multics.",
URL="http://www.rfc-editor.org/rfc/rfc590.txt"
}

@TECHREPORT{rfc591,
AUTHOR="D. C. Walden",
TITLE="Addition to the Very Distant Host specifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=591,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="A sentence correction notation that should be inserted in
Appendix F of BBN Report 1822.",
URL="http://www.rfc-editor.org/rfc/rfc591.txt"
}

@TECHREPORT{rfc592,
AUTHOR="R. W. Watson",
TITLE="Some thoughts on system design to facilitate resource sharing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=592,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="Proposes a system interconnection approach which would help in
moving toward more resource sharing on the ARPANET."
}

@TECHREPORT{rfc593,
AUTHOR="A. A. McKenzie and J. B. Postel",
TITLE="Telnet and {FTP} implementation schedule change",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=593,
PAGES=1,
DAYS=15,
MONTH=nov,
YEAR=1973,
URL="http://www.rfc-editor.org/rfc/rfc593.txt"
}

@TECHREPORT{rfc594,
AUTHOR="Jerry Burchfiel",
TITLE="Speedup of {Host-IMP} interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=594,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="A discussion on how to make the full performance capabilities
of the subnet available for interprocess communication."
}

@TECHREPORT{rfc595,
AUTHOR="W. Hathaway",
TITLE="Second thoughts in defense of the Telnet {Go-Ahead}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=595,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="This RFC is in reply to RFC 596.",
URL="http://www.rfc-editor.org/rfc/rfc595.txt"
}

@TECHREPORT{rfc596,
AUTHOR="Edward A. Taft",
TITLE="Second thoughts on Telnet {Go-Ahead}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=596,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="Cited objections to the requirement that hosts implement the
Telnet Go-Ahead (GA) command, as specified in the Telnet Protocol
Specification.",
URL="http://www.rfc-editor.org/rfc/rfc596.txt"
}

@TECHREPORT{rfc597,
AUTHOR="N. Neigus and Elizabeth J. Feinler",
TITLE="Host status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=597,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="This RFC provides the most current network maps, geographic
and logical, plus a list of hosts connected to the ARPANET.",
URL="http://www.rfc-editor.org/rfc/rfc597.txt"
}

@TECHREPORT{rfc598,
AUTHOR=" {{Network Information Center, Stanford Research Institute}}",
TITLE="{RFC} index - December {5,} 1973",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=598,
MONTH=dec,
YEAR=1973,
ABSTRACT="Lists RFCs 1-593."
}

@TECHREPORT{rfc599,
AUTHOR="R. Braden",
TITLE="Update on {NETRJS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=599,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="A status report and update on UCLA-CCN's remote job entry
service.",
URL="http://www.rfc-editor.org/rfc/rfc599.txt"
}

@TECHREPORT{rfc600,
AUTHOR="A. Berggreen",
TITLE="Interfacing an Illinois plasma terminal to the {ARPANET}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=600,
DAYS=15,
MONTH=nov,
YEAR=1973,
ABSTRACT="Discusses plans to map Plato terminal codes to network ASCII
for accessing the Plato system via the network using Telnet."
}

@TECHREPORT{rfc601,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (November {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=601,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="A report on Host traffic statistics for the month of November
1973. Updates RFC 586.",
URL="http://www.rfc-editor.org/rfc/rfc601.txt"
}

@TECHREPORT{rfc602,
AUTHOR="Robert M. Metcalfe",
TITLE={{"}The stockings were hung by the chimney with care{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=602,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="Susceptibility of ARPANET to security violations.",
URL="http://www.rfc-editor.org/rfc/rfc602.txt"
}

@TECHREPORT{rfc603,
AUTHOR="Jerry Burchfiel",
TITLE="Response to {RFC} {597:} Host status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=603,
PAGES=1,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="Questions about the ARPANET topology described in RFC 597.",
URL="http://www.rfc-editor.org/rfc/rfc603.txt"
}

@TECHREPORT{rfc604,
AUTHOR="J. B. Postel",
TITLE="Assigned link numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=604,
PAGES=2,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="Modifies official host-host protocol. Replaced by RFCs 997 and
990.",
URL="http://www.rfc-editor.org/rfc/rfc604.txt"
}

@TECHREPORT{rfc606,
AUTHOR="L. P. Deutsch",
TITLE="Host names on-line",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=606,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="Resolving differences in hostname-address mappings; see also
RFCs 627, 625, 623 and 608.",
URL="http://www.rfc-editor.org/rfc/rfc606.txt"
}

@TECHREPORT{rfc610,
AUTHOR="R. Winter and J. S. Hill and W. Greiff",
TITLE="Further datalanguage design concepts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=610,
PAGES=88,
DAYS=15,
MONTH=dec,
YEAR=1973,
ABSTRACT="Preliminary results of the language design; a model for data
languagea semantics; future considerations.",
URL="http://www.rfc-editor.org/rfc/rfc610.txt"
}

@TECHREPORT{rfc616,
AUTHOR="D. C. Walden",
TITLE="Latest network maps",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=616,
DAYS=15,
MONTH=feb,
YEAR=1973,
ABSTRACT="Geographic ad Topologic maps of the ARPANET of January 1974."
}

@TECHREPORT{rfc607,
AUTHOR="M. Krilanovich and G. Gregg",
TITLE="Comments on the File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=607,
DAYS=15,
MONTH=jan,
YEAR=1974,
ABSTRACT="An old version; see RFC 624; see also RFCs 614, 542 and 640.",
URL="http://www.rfc-editor.org/rfc/rfc607.txt"
}

@TECHREPORT{rfc608,
AUTHOR="M. D. Kudlick",
TITLE="Host names on-line",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=608,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1974,
ABSTRACT="Response to RFC 606; see also RFCs 627, 625 and 623.",
URL="http://www.rfc-editor.org/rfc/rfc608.txt"
}

@TECHREPORT{rfc609,
AUTHOR="B. Ferguson",
TITLE="Statement of upcoming move of {NIC/NLS} service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=609,
DAYS=15,
MONTH=jan,
YEAR=1974,
ABSTRACT="See also RFCs 621 and 620.",
URL="http://www.rfc-editor.org/rfc/rfc609.txt"
}

@TECHREPORT{rfc611,
AUTHOR="D. C. Walden",
TITLE="Two changes to the {IMP/Host} Protocol to improve user/network
communications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=611,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1974,
ABSTRACT="Expansion of Host-Going-Down and addition of Dead-Host-Status
Message.",
URL="http://www.rfc-editor.org/rfc/rfc611.txt"
}

@TECHREPORT{rfc612,
AUTHOR="A. A. McKenzie",
TITLE="Traffic statistics (December {1973)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=612,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1974,
ABSTRACT="A report on Host traffic statistics for the month of December
1973. Updates RFC 601.",
URL="http://www.rfc-editor.org/rfc/rfc612.txt"
}

@TECHREPORT{rfc613,
AUTHOR="A. A. McKenzie",
TITLE="Network connectivity: A response to {RFC} 603",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=613,
PAGES=1,
DAYS=15,
MONTH=jan,
YEAR=1974,
ABSTRACT="Remarks about connectivity and robustness of networks.",
URL="http://www.rfc-editor.org/rfc/rfc613.txt"
}

@TECHREPORT{rfc614,
AUTHOR="K. T. Pogran and N. Neigus",
TITLE={Response to {RFC} {607:} {"}Comments on the File Transfer Protocol{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=614,
DAYS=15,
MONTH=jan,
YEAR=1974,
ABSTRACT="See also RFCs 624, 542 and 640.",
URL="http://www.rfc-editor.org/rfc/rfc614.txt"
}

@TECHREPORT{rfc615,
AUTHOR="D. H. Crocker",
TITLE="Proposed Network Standard Data Pathname syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=615,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="A suggestion for a network wide standard for naming data (such
as files).",
URL="http://www.rfc-editor.org/rfc/rfc615.txt"
}

@TECHREPORT{rfc617,
AUTHOR="Edward A. Taft",
TITLE="Note on socket number assignment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=617,
DAYS=15,
MONTH=feb,
YEAR=1974,
ABSTRACT="Danger of imposing more fixed socket number requirements; see
also RFCs 542, 503 and 451.",
URL="http://www.rfc-editor.org/rfc/rfc617.txt"
}

@TECHREPORT{rfc618,
AUTHOR="Edward A. Taft",
TITLE="Few observations on {NCP} statistics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=618,
DAYS=15,
MONTH=feb,
YEAR=1974,
ABSTRACT="Distribution of NCP and IMP message types by actual
measurement.",
URL="http://www.rfc-editor.org/rfc/rfc618.txt"
}

@TECHREPORT{rfc619,
AUTHOR="W. E. Naylor and H. Opderbeck",
TITLE="Mean round-trip times in the {ARPANET}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=619,
PAGES=14,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="Actual measurements of round-trip times.",
URL="http://www.rfc-editor.org/rfc/rfc619.txt"
}

@TECHREPORT{rfc620,
AUTHOR="B. Ferguson",
TITLE="Request for monitor host table updates",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=620,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="Changes in the hosts Office-1 and SRI-ARC.",
URL="http://www.rfc-editor.org/rfc/rfc620.txt"
}

@TECHREPORT{rfc621,
AUTHOR="M. D. Kudlick",
TITLE="{NIC} user directories at {SRI} {ARC}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=621,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="Changes in user accounts at the NIC.",
URL="http://www.rfc-editor.org/rfc/rfc621.txt"
}

@TECHREPORT{rfc622,
AUTHOR="A. A. McKenzie",
TITLE="Scheduling {IMP/TIP} down time",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=622,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="Modification of previous policy.",
URL="http://www.rfc-editor.org/rfc/rfc622.txt"
}

@TECHREPORT{rfc623,
AUTHOR="M. Krilanovich",
TITLE="Comments on on-line host name service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=623,
PAGES=2,
DAYS=15,
MONTH=feb,
YEAR=1974,
ABSTRACT="See also RFCs 627, 625, 608 and 606.",
URL="http://www.rfc-editor.org/rfc/rfc623.txt"
}

@TECHREPORT{rfc624,
AUTHOR="M. Krilanovich and G. Gregg and W. Hathaway and J. A. White",
TITLE="This document replaces {RFC} {607,} which was inadvertently released while
still in rough draft form. It would be appreciated if {RFC} 607 were
disregarded, and this document considered the accurate statement of the
authors' opinions.",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=624,
MONTH=feb,
YEAR=1974,
URL="http://www.rfc-editor.org/rfc/rfc624.txt"
}

@TECHREPORT{rfc625,
AUTHOR="M. D. Kudlick and Elizabeth J. Feinler",
TITLE="On-line hostnames service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=625,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="See also RFCs 606, 608, 623 and 627.",
URL="http://www.rfc-editor.org/rfc/rfc625.txt"
}

@TECHREPORT{rfc626,
AUTHOR="L. Kleinrock and H. Opderbeck",
TITLE="On a possible lockup condition in {IMP} subnet due to message sequencing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=626,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="A potential problem in the IMP processing of messages. A
detailed description of how this condition can arise.",
URL="http://www.rfc-editor.org/rfc/rfc626.txt"
}

@TECHREPORT{rfc627,
AUTHOR="M. D. Kudlick and Elizabeth J. Feinler",
TITLE="{ASCII} text file of hostnames",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=627,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="See also RFCs 606, 608, 623 and 625.",
URL="http://www.rfc-editor.org/rfc/rfc627.txt"
}

@TECHREPORT{rfc628,
AUTHOR="M. L. Keeney",
TITLE="Status of {RFC} numbers and a note on pre-assigned journal numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=628,
PAGES=1,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="A method for getting the next RFC number to use on a new memo.",
URL="http://www.rfc-editor.org/rfc/rfc628.txt"
}

@TECHREPORT{rfc629,
AUTHOR="J. B. North",
TITLE="Scenario for using the Network Journal",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=629,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="An example of how to access information in the NIC's Journal
database.",
URL="http://www.rfc-editor.org/rfc/rfc629.txt"
}

@TECHREPORT{rfc630,
AUTHOR="J. M. Sussman",
TITLE="{FTP} error code usage for more reliable mail service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=630,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1974,
ABSTRACT="Describes FTP reply-code usage in TENEX mail processing.",
URL="http://www.rfc-editor.org/rfc/rfc630.txt"
}

@TECHREPORT{rfc631,
AUTHOR="A. Danthine",
TITLE="International meeting on minicomputers and data communication: Call for
papers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=631,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1974,
ABSTRACT="A meeting on data communications held January 1975 in Liege,
Belgium.",
URL="http://www.rfc-editor.org/rfc/rfc631.txt"
}

@TECHREPORT{rfc632,
AUTHOR="H. Opderbeck",
TITLE="Throughput degradations for single packet messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=632,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1974,
ABSTRACT="A study of packet throughput.",
URL="http://www.rfc-editor.org/rfc/rfc632.txt"
}

@TECHREPORT{rfc633,
AUTHOR="Alex A. McKenzie",
TITLE="{IMP/TIP} preventive maintenance schedule",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=633,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1974,
ABSTRACT="An old version; see RFC 638.",
URL="http://www.rfc-editor.org/rfc/rfc633.txt"
}

@TECHREPORT{rfc634,
AUTHOR="A. A. McKenzie",
TITLE="Change in network address for Haskins Lab",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=634,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1974,
ABSTRACT="A host a Haskins Lab changes its address from 5/3 to 9/3.",
URL="http://www.rfc-editor.org/rfc/rfc634.txt"
}

@TECHREPORT{rfc635,
AUTHOR="V. G. Cerf",
TITLE="Assessment of {ARPANET} protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=635,
DAYS=15,
MONTH=apr,
YEAR=1974,
ABSTRACT="Theoretical and practical motivation for redesign. Multipacket
messages; host retransmission; duplicate detection; sequencing;
acknowledgement."
}

@TECHREPORT{rfc636,
AUTHOR="Jerry Burchfiel and B. Cosell and Raymond Tomlinson and D. C. Walden",
TITLE="{TIP/Tenex} reliability improvements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=636,
DAYS=15,
MONTH=jun,
YEAR=1974,
ABSTRACT="Obtaining/maintaining connections; recovery from lost
connections; connection-state changes.",
URL="http://www.rfc-editor.org/rfc/rfc636.txt"
}

@TECHREPORT{rfc637,
AUTHOR="A. A. McKenzie",
TITLE="Change of network address for {SU-DSL}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=637,
PAGES=1,
DAYS=15,
MONTH=apr,
YEAR=1974,
ABSTRACT="A host at Stanford changes its address from 2/2 to 2/3.",
URL="http://www.rfc-editor.org/rfc/rfc637.txt"
}

@TECHREPORT{rfc640,
AUTHOR="J. B. Postel",
TITLE="Revised {FTP} reply codes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=640,
DAYS=15,
MONTH=jun,
YEAR=1974,
ABSTRACT="Updates RFC 542.",
URL="http://www.rfc-editor.org/rfc/rfc640.txt"
}

@TECHREPORT{rfc642,
AUTHOR="Jerry Burchfiel",
TITLE="Ready line philosophy and implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=642,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1974,
URL="http://www.rfc-editor.org/rfc/rfc642.txt"
}

@TECHREPORT{rfc643,
AUTHOR="E. Mader",
TITLE="Network Debugging Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=643,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1974,
ABSTRACT="To be used in an implementation of a PDP-11 network bootstrap
device and a cross-network debugger.",
URL="http://www.rfc-editor.org/rfc/rfc643.txt"
}

@TECHREPORT{rfc644,
AUTHOR="R. Thomas",
TITLE="On the problem of signature authentication for network mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=644,
DAYS=15,
MONTH=jul,
YEAR=1974,
ABSTRACT="Proposes that the mail sender be an authorized system process
and that the mail sender and mail receiver processes exchange a
password. The sender process takes responsibility for authentication of
the signature on the mail.",
URL="http://www.rfc-editor.org/rfc/rfc644.txt"
}

@TECHREPORT{rfc645,
AUTHOR="D. H. Crocker",
TITLE="Network Standard Data Specification syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=645,
DAYS=15,
MONTH=jun,
YEAR=1974,
ABSTRACT="Providing a mechanism for specifying all attributes of a
collection of bits; see also RFC 615."
}

@TECHREPORT{rfc647,
AUTHOR="M. A. Padlipsky",
TITLE="Proposed protocol for connecting host computers to {ARPA-like} networks via
front end processors",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=647,
DAYS=15,
MONTH=nov,
YEAR=1974,
ABSTRACT="Approaches to Front-End protocol processing using available
hardware and software."
}

@TECHREPORT{rfc651,
AUTHOR="D. H. Crocker",
TITLE="Revised Telnet status option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=651,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Revises the Telnet Option for communicating the status of all
Telnet options over the network.",
URL="http://www.rfc-editor.org/rfc/rfc651.txt"
}

@TECHREPORT{rfc652,
AUTHOR="D. H. Crocker",
TITLE="Telnet output carriage-return disposition option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=652,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Defines a Telnet option for specific control of Carriage
Return.",
URL="http://www.rfc-editor.org/rfc/rfc652.txt"
}

@TECHREPORT{rfc653,
AUTHOR="D. H. Crocker",
TITLE="Telnet output horizontal tabstops option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=653,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Defines a Telnet option for setting the stops for Horizontal
Tab.",
URL="http://www.rfc-editor.org/rfc/rfc653.txt"
}

@TECHREPORT{rfc654,
AUTHOR="D. H. Crocker",
TITLE="Telnet output horizontal tab disposition option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=654,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Defines a Telnet option for specific control of Horizontal
Tab.",
URL="http://www.rfc-editor.org/rfc/rfc654.txt"
}

@TECHREPORT{rfc655,
AUTHOR="D. H. Crocker",
TITLE="Telnet output formfeed disposition option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=655,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Defines a Telnet option for specific control of Form Feed.",
URL="http://www.rfc-editor.org/rfc/rfc655.txt"
}

@TECHREPORT{rfc656,
AUTHOR="D. H. Crocker",
TITLE="Telnet output vertical tabstops option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=656,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Defines a Telnet option for setting the stops for Vertical
Tab.",
URL="http://www.rfc-editor.org/rfc/rfc656.txt"
}

@TECHREPORT{rfc657,
AUTHOR="D. H. Crocker",
TITLE="Telnet output vertical tab disposition option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=657,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Defines a Telnet option for specific control of Vertical Tab.",
URL="http://www.rfc-editor.org/rfc/rfc657.txt"
}

@TECHREPORT{rfc658,
AUTHOR="D. H. Crocker",
TITLE="Telnet output linefeed disposition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=658,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Defines a Telnet option for specific control of Line Feed.",
URL="http://www.rfc-editor.org/rfc/rfc658.txt"
}

@TECHREPORT{rfc659,
AUTHOR="J. B. Postel",
TITLE="Announcing additional Telnet options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=659,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Options defined in RFCs 651-658.",
URL="http://www.rfc-editor.org/rfc/rfc659.txt"
}

@TECHREPORT{rfc660,
AUTHOR="D. C. Walden",
TITLE="Some changes to the {IMP} and the {IMP/Host} interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=660,
DAYS=15,
MONTH=oct,
YEAR=1974,
ABSTRACT="Decoupling of message number sequences of hosts; host-host
access control; message number window; messages outside normal
mechanism; see also BBN 1822.",
URL="http://www.rfc-editor.org/rfc/rfc660.txt"
}

@TECHREPORT{rfc661,
AUTHOR="J. B. Postel",
TITLE="Protocol information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=661,
DAYS=15,
MONTH=nov,
YEAR=1974,
ABSTRACT="This RFC has been replaced by RFC 991."
}

@TECHREPORT{rfc662,
AUTHOR="R. Kanodia",
TITLE="Performance improvement in {ARPANET} file transfers from Multics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=662,
DAYS=15,
MONTH=nov,
YEAR=1974,
ABSTRACT="Experimenting with host output buffers to improve throughput.",
URL="http://www.rfc-editor.org/rfc/rfc662.txt"
}

@TECHREPORT{rfc663,
AUTHOR="R. Kanodia",
TITLE="Lost message detection and recovery protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=663,
DAYS=15,
MONTH=nov,
YEAR=1974,
ABSTRACT="Proposed extension of host-host protocol; see also RFCs 534,
516, 512, 492 and 467.",
URL="http://www.rfc-editor.org/rfc/rfc663.txt"
}

@TECHREPORT{rfc666,
AUTHOR="M. A. Padlipsky",
TITLE="Specification of the Unified {User-Level} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=666,
DAYS=15,
MONTH=nov,
YEAR=1974,
ABSTRACT="Discusses and proposes a common command language."
}

@TECHREPORT{rfc667,
AUTHOR="S. G. Chipman",
TITLE="{BBN} host ports",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=667,
DAYS=15,
MONTH=dec,
YEAR=1974,
ABSTRACT="Approved scheme to connect host ports to the network."
}

@TECHREPORT{rfc669,
AUTHOR="D. W. Dodds",
TITLE="November, {1974,} survey of {New-Protocol} Telnet servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=669,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1974,
ABSTRACT="An earlier poll of Telnet server implementation status.
Updates RFC 702; see also RFCs 703 and 679."
}

@TECHREPORT{rfc671,
AUTHOR="R. E. Schantz",
TITLE="Note on Reconnection Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=671,
DAYS=15,
MONTH=dec,
YEAR=1974,
ABSTRACT="Experience with implementation in RSEXEC context."
}

@TECHREPORT{rfc672,
AUTHOR="R. E. Schantz",
TITLE="Multi-site data collection facility",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=672,
DAYS=15,
MONTH=dec,
YEAR=1974,
ABSTRACT="Applicability of TIP/Tenex protocols beyond TIP accounting.",
URL="http://www.rfc-editor.org/rfc/rfc672.txt"
}

@TECHREPORT{rfc674,
AUTHOR="J. B. Postel and J. A. White",
TITLE="Procedure call documents: Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=674,
DAYS=15,
MONTH=dec,
YEAR=1974,
ABSTRACT="A host level protocol used in the NSW--a slightly constrained
version of ARPANET Host-to-Host protocol, affecting allocation, RFNM
wait, and retransmission; see also RFC 684.",
URL="http://www.rfc-editor.org/rfc/rfc674.txt"
}

@TECHREPORT{rfc675,
AUTHOR="V. G. Cerf and Y. Dalal and C. A. Sunshine",
TITLE="Specification of {Internet} Transmission Control Program",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=675,
PAGES=70,
DAYS=15,
MONTH=dec,
YEAR=1974,
ABSTRACT="The first detailed specification of TCP; see RFC 793.",
URL="http://www.rfc-editor.org/rfc/rfc675.txt"
}

@TECHREPORT{rfc678,
AUTHOR="J. B. Postel",
TITLE="Standard file formats",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=678,
DAYS=15,
MONTH=dec,
YEAR=1974,
ABSTRACT="For transmission of documents across different environments.",
URL="http://www.rfc-editor.org/rfc/rfc678.txt"
}

@TECHREPORT{rfc700,
AUTHOR="E. Mader and William W. Plummer and Raymond Tomlinson",
TITLE="Protocol experiment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=700,
DAYS=15,
MONTH=aug,
YEAR=1974,
ABSTRACT="Describes a protocol based loosely on a very early version of
TCP, used to send data to a printer server.",
URL="http://www.rfc-editor.org/rfc/rfc700.txt"
}

@TECHREPORT{rfc701,
AUTHOR="D. W. Dodds",
TITLE="August, {1974,} survey of {New-Protocol} Telnet servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=701,
DAYS=15,
MONTH=aug,
YEAR=1974,
ABSTRACT="An earlier poll of Telnet server implementation status; see
also RFCs 703, 702, 679 and 669.",
URL="http://www.rfc-editor.org/rfc/rfc701.txt"
}

@TECHREPORT{rfc702,
AUTHOR="D. W. Dodds",
TITLE="September, {1974,} survey of {New-Protocol} Telnet servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=702,
PAGES=3,
DAYS=15,
MONTH=sep,
YEAR=1974,
ABSTRACT="An earlier poll of Telnet server implementation status; see
also RFC's703, 701, 679, and 669.",
URL="http://www.rfc-editor.org/rfc/rfc702.txt"
}

@TECHREPORT{rfc677,
AUTHOR="P. Johnson and R. Thomas",
TITLE="Maintenance of duplicate databases",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=677,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1975,
URL="http://www.rfc-editor.org/rfc/rfc677.txt"
}

@TECHREPORT{rfc679,
AUTHOR="D. W. Dodds",
TITLE="February, {1975,} survey of {New-Protocol} Telnet servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=679,
DAYS=15,
MONTH=feb,
YEAR=1975,
ABSTRACT="An earlier poll of Telnet server implementation status.
Updates RFCs 701, 702 and 669; see also RFC 703."
}

@TECHREPORT{rfc680,
AUTHOR="Theodore Myer and D. Henderson",
TITLE="Message Transmission Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=680,
DAYS=15,
MONTH=apr,
YEAR=1975,
ABSTRACT="Extends message field definition beyond RFC 561 attempts to
establish syntactic and semantic standards for ARPANET; see also RFCs
733 and 822."
}

@TECHREPORT{rfc681,
AUTHOR="S. Holmgren",
TITLE="Network {UNIX}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=681,
DAYS=15,
MONTH=mar,
YEAR=1975,
ABSTRACT="Capabilities as an ARPANET Mini-Host: standard I/O, Telnet,
NCP, Hardware/Software requirements, reliability, availability.",
URL="http://www.rfc-editor.org/rfc/rfc681.txt"
}

@TECHREPORT{rfc683,
AUTHOR="R. Clements",
TITLE="{FTPSRV} - Tenex extension for paged files",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=683,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1975,
ABSTRACT="Defines an extension to FTP for page-mode transfers between
Tenex systems; also discusses file transfer reliability.",
URL="http://www.rfc-editor.org/rfc/rfc683.txt"
}

@TECHREPORT{rfc684,
AUTHOR="R. E. Schantz",
TITLE="Commentary on procedure calling as a network protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=684,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1975,
ABSTRACT="Describes issues in designing distributed computing systems.
Shortcomings of RFC 674; see also RFCs 542 and 354.",
URL="http://www.rfc-editor.org/rfc/rfc684.txt"
}

@TECHREPORT{rfc685,
AUTHOR="M. Beeler",
TITLE="Response time in cross network debugging",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=685,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1975,
ABSTRACT="This memo discusses the contribution of ARPANET communication
to response time.",
URL="http://www.rfc-editor.org/rfc/rfc685.txt"
}

@TECHREPORT{rfc686,
AUTHOR="B. Harvey",
TITLE="Leaving well enough alone",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=686,
PAGES=9,
DAYS=15,
MONTH=may,
YEAR=1975,
ABSTRACT="Discusses the difference between early and later versions of
FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.",
URL="http://www.rfc-editor.org/rfc/rfc686.txt"
}

@TECHREPORT{rfc687,
AUTHOR="D. C. Walden",
TITLE="{IMP/Host} and {Host/IMP} Protocol changes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=687,
DAYS=15,
MONTH=jun,
YEAR=1975,
ABSTRACT="This RFC discusses addressing hosts on more than 63 IMPs, and
other backwards compatible expansions; see also RFCs 690 and 692.",
URL="http://www.rfc-editor.org/rfc/rfc687.txt"
}

@TECHREPORT{rfc688,
AUTHOR="D. C. Walden",
TITLE="Tentative schedule for the new Telnet implementation for the {TIP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=688,
PAGES=1,
DAYS=15,
MONTH=jun,
YEAR=1975,
URL="http://www.rfc-editor.org/rfc/rfc688.txt"
}

@TECHREPORT{rfc689,
AUTHOR="R. Clements",
TITLE="Tenex {NCP} finite state machine for connections",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=689,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1975,
ABSTRACT="Describes the internal states of an NCP connection in the
Tenex implementation.",
URL="http://www.rfc-editor.org/rfc/rfc689.txt"
}

@TECHREPORT{rfc690,
AUTHOR="J. B. Postel",
TITLE="Comments on the proposed {Host/IMP} Protocol changes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=690,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1975,
ABSTRACT="Comments on suggestions in RFC 687; see also RFCs 692 and 696.",
URL="http://www.rfc-editor.org/rfc/rfc690.txt"
}

@TECHREPORT{rfc691,
AUTHOR="B. Harvey",
TITLE="One more try on the {FTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=691,
DAYS=15,
MONTH=jun,
YEAR=1975,
ABSTRACT="A slight revision of RFC 686, regarding the subject of print
files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.",
URL="http://www.rfc-editor.org/rfc/rfc691.txt"
}

@TECHREPORT{rfc692,
AUTHOR="S. M. Wolfe",
TITLE="Comments on {IMP/Host} Protocol changes {(RFCs} 687 and {690)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=692,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1975,
ABSTRACT="A proposed solution to the problem of combined length of IMP
and Host leaders; see also RFCs 696, 690 and 687.",
URL="http://www.rfc-editor.org/rfc/rfc692.txt"
}

@TECHREPORT{rfc694,
AUTHOR="J. B. Postel",
TITLE="Protocol information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=694,
DAYS=15,
MONTH=jun,
YEAR=1975,
ABSTRACT="This RFC has been replaced by RFC 991."
}

@TECHREPORT{rfc695,
AUTHOR="M. Krilanovich",
TITLE="Official change in {Host-Host} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=695,
DAYS=15,
MONTH=jul,
YEAR=1975,
ABSTRACT="Corrects an ambiguity concerning the ERR command; changes NIC
8246 and NIC 7104.",
URL="http://www.rfc-editor.org/rfc/rfc695.txt"
}

@TECHREPORT{rfc696,
AUTHOR="V. G. Cerf",
TITLE="Comments on the {IMP/Host} and {Host/IMP} Protocol changes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=696,
DAYS=15,
MONTH=jul,
YEAR=1975,
ABSTRACT="Observations on current international standards
recommendations from IFIP working group 6.1; see also RFCs 692, 690 687."
}

@TECHREPORT{rfc697,
AUTHOR="J. Lieb",
TITLE="{CWD} command of {FTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=697,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1975,
ABSTRACT={Discusses FTP login access to {"}files only{"} directories.},
URL="http://www.rfc-editor.org/rfc/rfc697.txt"
}

@TECHREPORT{rfc698,
AUTHOR="T. Mock",
TITLE="Telnet extended {ASCII} option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=698,
DAYS=15,
MONTH=jul,
YEAR=1975,
ABSTRACT="Describes an option to allow transmission of a special kind of
extended ASCII used at the Stanford AI and MIT AI Labs.",
URL="http://www.rfc-editor.org/rfc/rfc698.txt"
}

@TECHREPORT{rfc703,
AUTHOR="D. W. Dodds",
TITLE="July, {1975,} survey of {New-Protocol} Telnet Servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=703,
PAGES=3,
DAYS=15,
MONTH=jul,
YEAR=1975,
ABSTRACT="A poll of Telnet servers to check implementation status and
Telnet options. Updates RFCs 702, 701, 679 and 669.",
URL="http://www.rfc-editor.org/rfc/rfc703.txt"
}

@TECHREPORT{rfc704,
AUTHOR="P. J. Santos",
TITLE="{IMP/Host} and {Host/IMP} Protocol change",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=704,
DAYS=15,
MONTH=sep,
YEAR=1975,
ABSTRACT="Describes the changes to the 1822 interface to eliminate the
restriction of 63 IMPs.",
URL="http://www.rfc-editor.org/rfc/rfc704.txt"
}

@TECHREPORT{rfc705,
AUTHOR="R. F. Bryan",
TITLE="Front-end Protocol {B6700} version",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=705,
DAYS=15,
MONTH=nov,
YEAR=1975,
ABSTRACT="This RFC describes a protocol used between a PDP-11 (the
ARPANET front end) and a B6700 to support network communication.",
URL="http://www.rfc-editor.org/rfc/rfc705.txt"
}

@TECHREPORT{rfc706,
AUTHOR="J. B. Postel",
TITLE="On the junk mail problem",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=706,
DAYS=15,
MONTH=nov,
YEAR=1975,
ABSTRACT={A short note pointing out that the ARPANET maybe subject to a
{"}denial of service{"} attack by a misbehaving host.},
URL="http://www.rfc-editor.org/rfc/rfc706.txt"
}

@TECHREPORT{rfc707,
AUTHOR="J. A. White",
TITLE="High-level framework for network-based resource sharing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=707,
DAYS=15,
MONTH=dec,
YEAR=1975,
ABSTRACT="A description of a programming environment for network-based
programs; see also RFC 708.",
URL="http://www.rfc-editor.org/rfc/rfc707.txt"
}

@TECHREPORT{rfc708,
AUTHOR="J. A. White",
TITLE="Elements of a Distributed Programming System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=708,
PAGES=30,
DAYS=15,
MONTH=jan,
YEAR=1976,
ABSTRACT="A description of a distributed programming system; see also
RFC 707.",
URL="http://www.rfc-editor.org/rfc/rfc708.txt"
}

@TECHREPORT{rfc712,
AUTHOR="J. E. Donnelley",
TITLE="Distributed Capability Computing System {(DCCS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=712,
DAYS=15,
MONTH=feb,
YEAR=1976,
ABSTRACT="A description of a Distributed Capability based computing
system."
}

@TECHREPORT{rfc713,
AUTHOR="J. Haverty",
TITLE="{MSDTP-Message} Services Data Transmission Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=713,
PAGES=22,
DAYS=15,
MONTH=apr,
YEAR=1976,
ABSTRACT="The specification of a set of Data Primitives for building
interactive services.",
URL="http://www.rfc-editor.org/rfc/rfc713.txt"
}

@TECHREPORT{rfc714,
AUTHOR="A. A. McKenzie",
TITLE="{Host-Host} Protocol for an {ARPANET-Type} Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=714,
DAYS=15,
MONTH=apr,
YEAR=1976,
ABSTRACT="A specification of a NCP-like protocol for an ARPA-like
network. Interesting to compare to the NCP specification to see what the
author would do differently."
}

@TECHREPORT{rfc716,
AUTHOR="D. C. Walden and J. Levin",
TITLE="Interim Revision to Appendix F of {BBN} 1822",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=716,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1976,
ABSTRACT="A short note updating the specification of the Very Distant
Host 1822 interface.",
URL="http://www.rfc-editor.org/rfc/rfc716.txt"
}

@TECHREPORT{rfc717,
AUTHOR="J. B. Postel",
TITLE="Assigned Network Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=717,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1976,
ABSTRACT="This RFC has been replaced by RFC 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc717.txt"
}

@TECHREPORT{rfc718,
AUTHOR="J. B. Postel",
TITLE="Comments on {RCTE} from the Tenex Implementation Experience",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=718,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1976,
ABSTRACT="A short note on the Tenex implementation of RCTE; see also
RFCs 726 and 719.",
URL="http://www.rfc-editor.org/rfc/rfc718.txt"
}

@TECHREPORT{rfc719,
AUTHOR="J. B. Postel",
TITLE="Discussion on {RCTE}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=719,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1976,
ABSTRACT="A short discussion of RCTE implementation issues; see also
RFCs 726 and 718.",
URL="http://www.rfc-editor.org/rfc/rfc719.txt"
}

@TECHREPORT{rfc720,
AUTHOR="D. H. Crocker",
TITLE="Address Specification Syntax for Network Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=720,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1976,
ABSTRACT="A discussion of computer mail addresses, with comments on real
names vs. mailboxes, and mailing lists; see also RFC 819.",
URL="http://www.rfc-editor.org/rfc/rfc720.txt"
}

@TECHREPORT{rfc721,
AUTHOR="L. L. Garlick",
TITLE="{Out-of-Band} Control Signals in a {Host-to-Host} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=721,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=1976,
ABSTRACT="A discussion of the control signals in transport protocols
(e.g., NCP's Interrupt or TCP's Urgent).",
URL="http://www.rfc-editor.org/rfc/rfc721.txt"
}

@TECHREPORT{rfc722,
AUTHOR="J. Haverty",
TITLE="Thoughts on Interactions in Distributed Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=722,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=1976,
ABSTRACT="A discussion on the design of interactive distributed services
and the kinds of primitive operations that are needed.",
URL="http://www.rfc-editor.org/rfc/rfc722.txt"
}

@TECHREPORT{rfc724,
AUTHOR="D. H. Crocker and K. T. Pogran and J. Vittal and D. Henderson",
TITLE="Proposed official standard for the format of {ARPA} Network messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=724,
DAYS=15,
MONTH=may,
YEAR=1977,
ABSTRACT="An old version; see RFC 822.",
URL="http://www.rfc-editor.org/rfc/rfc724.txt"
}

@TECHREPORT{rfc725,
AUTHOR="John Day and Gary R. Grossman",
TITLE="{RJE} protocol for a resource sharing network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=725,
DAYS=15,
MONTH=mar,
YEAR=1977,
ABSTRACT="Describes a possible Remote Job Entry protocol.",
URL="http://www.rfc-editor.org/rfc/rfc725.txt"
}

@TECHREPORT{rfc726,
AUTHOR="J. B. Postel and D. H. Crocker",
TITLE="Remote Controlled Transmission and Echoing Telnet option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=726,
DAYS=15,
MONTH=mar,
YEAR=1977,
ABSTRACT="Defines a Telnet option for controlling the transmission and
echoing of data to smooth the response to use in high transmission delay
environments; see also RFCs 719 and 718.",
URL="http://www.rfc-editor.org/rfc/rfc726.txt"
}

@TECHREPORT{rfc727,
AUTHOR="M. R. Crispin",
TITLE="Telnet logout option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=727,
DAYS=15,
MONTH=apr,
YEAR=1977,
ABSTRACT="Defines a Telnet option for causing a logout.",
URL="http://www.rfc-editor.org/rfc/rfc727.txt"
}

@TECHREPORT{rfc728,
AUTHOR="John Day",
TITLE="Minor pitfall in the Telnet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=728,
DAYS=15,
MONTH=apr,
YEAR=1977,
ABSTRACT="This RFC warns of the possibility of an unexpected occurence
in Telnet resulting from the interaction between option subnegotiations
and the Telnet SYNCH operation.",
URL="http://www.rfc-editor.org/rfc/rfc728.txt"
}

@TECHREPORT{rfc729,
AUTHOR="D. H. Crocker",
TITLE="Telnet byte macro option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=729,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1977,
ABSTRACT="An old version; see RFC 735.",
URL="http://www.rfc-editor.org/rfc/rfc729.txt"
}

@TECHREPORT{rfc730,
AUTHOR="J. B. Postel",
TITLE="Extensible field addressing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=730,
DAYS=15,
MONTH=may,
YEAR=1977,
ABSTRACT="Discusses some ideas on addressing that come up in the context
of changing from 8-bit to 24-bit network addresses.",
URL="http://www.rfc-editor.org/rfc/rfc730.txt"
}

@TECHREPORT{rfc731,
AUTHOR="J. Day",
TITLE="Telnet Data Entry Terminal option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=731,
PAGES=14,
DAYS=15,
MONTH=jun,
YEAR=1977,
ABSTRACT="An old version; see RFC 732.",
URL="http://www.rfc-editor.org/rfc/rfc731.txt"
}

@TECHREPORT{rfc733,
AUTHOR="D. H. Crocker and J. Vittal and K. T. Pogran and D. Henderson",
TITLE="Standard for the format of {ARPA} network text messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=733,
DAYS=15,
MONTH=nov,
YEAR=1977,
ABSTRACT="Specification of the format for the headers of computer mail.
An old version; see RFC 822.",
URL="http://www.rfc-editor.org/rfc/rfc733.txt"
}

@TECHREPORT{rfc734,
AUTHOR="M. R. Crispin",
TITLE="{SUPDUP} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=734,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=1977,
ABSTRACT="Description of a terminal control protocol used at Stanford
and MIT; see also RFCs 736, 746-749.",
URL="http://www.rfc-editor.org/rfc/rfc734.txt"
}

@TECHREPORT{rfc735,
AUTHOR="D. H. Crocker and R. H. Gumpertz",
TITLE="Revised Telnet byte macro option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=735,
DAYS=15,
MONTH=nov,
YEAR=1977,
ABSTRACT="Defines a Telnet option for assigning codes to stand for
strings in Telnet connections. Replaces RFC 729. Obsoletes NIC 40306.",
URL="http://www.rfc-editor.org/rfc/rfc735.txt"
}

@TECHREPORT{rfc736,
AUTHOR="M. R. Crispin",
TITLE="Telnet {SUPDUP} option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=736,
DAYS=15,
MONTH=oct,
YEAR=1977,
ABSTRACT="Defines the procedure for negotiating to use the SUPDUP,
protocol as a Telnet option; see also RFCs 734, 746, 747 and 749.",
URL="http://www.rfc-editor.org/rfc/rfc736.txt"
}

@TECHREPORT{rfc737,
AUTHOR="K. Harrenstien",
TITLE="{FTP} extension: {XSEN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=737,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1977,
ABSTRACT="An extension to the Mail procedures. This function is
incorporated in the SMTP; see also RFC 821.",
URL="http://www.rfc-editor.org/rfc/rfc737.txt"
}

@TECHREPORT{rfc738,
AUTHOR="K. Harrenstien",
TITLE="Time server",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=738,
PAGES=1,
DAYS=15,
MONTH=oct,
YEAR=1977,
ABSTRACT="Defines the Time Server Protocol; see IEN 142 for the TCP and
VDP versions.",
URL="http://www.rfc-editor.org/rfc/rfc738.txt"
}

@TECHREPORT{rfc739,
AUTHOR="J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=739,
PAGES=11,
DAYS=15,
MONTH=nov,
YEAR=1977,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc739.txt"
}

@TECHREPORT{rfc740,
AUTHOR="R. Braden",
TITLE="{NETRJS} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=740,
DAYS=15,
MONTH=nov,
YEAR=1977,
ABSTRACT="Defines the protocol used for Remote Job Entry on the UCLA CCN
IBM system; replaces RFCs 599 and 189.",
URL="http://www.rfc-editor.org/rfc/rfc740.txt"
}

@TECHREPORT{rfc741,
AUTHOR="D. Cohen",
TITLE="Specifications for the Network Voice Protocol {(NVP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=741,
PAGES=30,
DAYS=15,
MONTH=nov,
YEAR=1977,
ABSTRACT="Defines the protocol used in the ARPANET packet speech
experiments. Replaced by NVP-II and ST for Internet packet speech
experiments. ST is documented in ISN 119; NVP-II is documented in an ISI
Internal memo.",
URL="http://www.rfc-editor.org/rfc/rfc741.txt"
}

@TECHREPORT{rfc742,
AUTHOR="K. Harrenstien",
TITLE="{NAME/FINGER} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=742,
PAGES=7,
DAYS=15,
MONTH=dec,
YEAR=1977,
ABSTRACT={Defines the Name or Finger Protocol which allows one to get
{"}who is on{"} or {"}where is user x{"} information from another host.},
URL="http://www.rfc-editor.org/rfc/rfc742.txt"
}

@TECHREPORT{rfc743,
AUTHOR="K. Harrenstien",
TITLE="{FTP} extension: {XRSQ/XRCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=743,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1977,
ABSTRACT="An extension to FTP mail to allow more efficient transmission
of computer mail. Now incorporated into SMTP; see RFC788.",
URL="http://www.rfc-editor.org/rfc/rfc743.txt"
}

@TECHREPORT{rfc744,
AUTHOR="J. Sattley",
TITLE="{MARS} - a Message Archiving and Retrieval Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=744,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1978,
ABSTRACT="The description of a database service for computer mail
messages, which operates via computer mail.",
URL="http://www.rfc-editor.org/rfc/rfc744.txt"
}

@TECHREPORT{rfc745,
AUTHOR="M. Beeler",
TITLE="{JANUS} interface specifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=745,
DAYS=15,
MONTH=mar,
YEAR=1978,
ABSTRACT="The specification of a symmetrical 1822 style interface.",
URL="http://www.rfc-editor.org/rfc/rfc745.txt"
}

@TECHREPORT{rfc746,
AUTHOR="R. Stallman",
TITLE="{SUPDUP} graphics extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=746,
DAYS=15,
MONTH=mar,
YEAR=1978,
ABSTRACT="An extension of SUPDUP for Graphics; see also RFCs 734, 736,
747 and 749.",
URL="http://www.rfc-editor.org/rfc/rfc746.txt"
}

@TECHREPORT{rfc747,
AUTHOR="M. R. Crispin",
TITLE="Recent extensions to the {SUPDUP} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=747,
DAYS=15,
MONTH=mar,
YEAR=1978,
ABSTRACT="An update to the SUPDUP protocol (RFC 734); see also RFCs 749,
746 and 736.",
URL="http://www.rfc-editor.org/rfc/rfc747.txt"
}

@TECHREPORT{rfc748,
AUTHOR="M. R. Crispin",
TITLE="Telnet randomly-lose option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=748,
DAYS=15,
MONTH=apr,
YEAR=1978,
ABSTRACT="Defines this Telnet option (note the date of this memo).",
URL="http://www.rfc-editor.org/rfc/rfc748.txt"
}

@TECHREPORT{rfc749,
AUTHOR="B. S. Greenberg",
TITLE="Telnet {SUPDUP-Output} option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=749,
DAYS=15,
MONTH=sep,
YEAR=1978,
ABSTRACT="Updates RFC 736; see also RFCs 734, 746, and 747.",
URL="http://www.rfc-editor.org/rfc/rfc749.txt"
}

@TECHREPORT{rfc750,
AUTHOR="J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=750,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=1978,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc750.txt"
}

@TECHREPORT{rfc751,
AUTHOR="P. D. Lebling",
TITLE="Survey of {FTP} mail and {MLFL}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=751,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1978,
ABSTRACT="A survey of hosts' responses to probes of their FTP servers to
see if servers (a) accept mail for unknown users and (b) support the
MAIL and MLFL commands.",
URL="http://www.rfc-editor.org/rfc/rfc751.txt"
}

@TECHREPORT{rfc752,
AUTHOR="M. R. Crispin",
TITLE="Universal host table",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=752,
DAYS=15,
MONTH=jan,
YEAR=1979,
ABSTRACT="Describes the host table used at MIT and Stanford. This has
several extensions and generalizations from the NIC standard and the
table used by most Tenex and TOPS20 hosts.",
URL="http://www.rfc-editor.org/rfc/rfc752.txt"
}

@TECHREPORT{rfc753,
AUTHOR="J. B. Postel",
TITLE="Internet Message Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=753,
PAGES=56,
DAYS=15,
MONTH=mar,
YEAR=1979,
ABSTRACT="An old version; see RFC 759.",
URL="http://www.rfc-editor.org/rfc/rfc753.txt"
}

@TECHREPORT{rfc754,
AUTHOR="J. B. Postel",
TITLE="Out-of-net host addresses for mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=754,
DAYS=15,
MONTH=apr,
YEAR=1979,
ABSTRACT="A discussion of options for addressing computer mail beyond
the ARPANET.",
URL="http://www.rfc-editor.org/rfc/rfc754.txt"
}

@TECHREPORT{rfc755,
AUTHOR="J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=755,
PAGES=12,
DAYS=15,
MONTH=may,
YEAR=1979,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc755.txt"
}

@TECHREPORT{rfc756,
AUTHOR="J. R. Pickens and Elizabeth J. Feinler and J. E. Mathis",
TITLE="{NIC} name server - a datagram-based information utility",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=756,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1979,
ABSTRACT="Describes a Host Name to Address look up service.",
URL="http://www.rfc-editor.org/rfc/rfc756.txt"
}

@TECHREPORT{rfc757,
AUTHOR="D. P. Deutsch",
TITLE="Suggested solution to the naming, addressing, and delivery problem for
{ARPANET} message systems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=757,
DAYS=15,
MONTH=sep,
YEAR=1979,
ABSTRACT="Discusses several proposals for handing the name to address to
route processing for computer mail. Favors a solution based on
unique-ids and a data base, see also RFCs 759, 821 and 822.",
URL="http://www.rfc-editor.org/rfc/rfc757.txt"
}

@TECHREPORT{rfc758,
AUTHOR="J. B. Postel",
TITLE="Obsoletes {RFCs:} {755,} {750,739,} {604,} {503,} {433,} 349 Obsoletes
{IENs:} 93",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=758,
MONTH=aug,
YEAR=1979,
URL="http://www.rfc-editor.org/rfc/rfc758.txt"
}

@TECHREPORT{rfc759,
AUTHOR="J. B. Postel",
TITLE="Internet Message Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=759,
PAGES=71,
DAYS=15,
MONTH=aug,
YEAR=1980,
ABSTRACT="The definition of the protocol and format for the exchange of
multimedia mail. Replaces RFC 753.",
URL="http://www.rfc-editor.org/rfc/rfc759.txt"
}

@TECHREPORT{rfc760,
AUTHOR="J. B. Postel",
TITLE="{DoD} standard Internet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=760,
PAGES=42,
DAYS=15,
MONTH=jan,
YEAR=1980,
ABSTRACT="An old version; see RFC 791.",
URL="http://www.rfc-editor.org/rfc/rfc760.txt"
}

@TECHREPORT{rfc761,
AUTHOR="J. B. Postel",
TITLE="{DoD} standard Transmission Control Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=761,
PAGES=84,
DAYS=15,
MONTH=jan,
YEAR=1980,
ABSTRACT="An old version; see RFC 793.",
URL="http://www.rfc-editor.org/rfc/rfc761.txt"
}

@TECHREPORT{rfc762,
AUTHOR="J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=762,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=1980,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc762.txt"
}

@TECHREPORT{rfc763,
AUTHOR="M. D. Abrams",
TITLE="Role mailboxes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=763,
DAYS=15,
MONTH=may,
YEAR=1980,
ABSTRACT={A call for mailboxes with role names, such as {"}Management{"}.},
URL="http://www.rfc-editor.org/rfc/rfc763.txt"
}

@TECHREPORT{rfc764,
AUTHOR="J. B. Postel",
TITLE="Telnet Protocol specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=764,
PAGES=15,
DAYS=15,
MONTH=jun,
YEAR=1980,
ABSTRACT="The specification of Telnet.",
URL="http://www.rfc-editor.org/rfc/rfc764.txt"
}

@TECHREPORT{rfc765,
AUTHOR="J. B. Postel",
TITLE="File Transfer Protocol specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=765,
DAYS=15,
MONTH=jun,
YEAR=1980,
ABSTRACT="The specification of FTP.",
URL="http://www.rfc-editor.org/rfc/rfc765.txt"
}

@TECHREPORT{rfc766,
AUTHOR="J. B. Postel",
TITLE="Internet Protocol Handbook: Table of contents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=766,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1980,
ABSTRACT="An out-of-date table of contents for the Internet Protocol
Handbook.",
URL="http://www.rfc-editor.org/rfc/rfc766.txt"
}

@TECHREPORT{rfc767,
AUTHOR="J. B. Postel",
TITLE="Structured format for transmission of multi-media documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=767,
PAGES=34,
DAYS=15,
MONTH=aug,
YEAR=1980,
ABSTRACT="The definition of the format for the document of a multimedia
message.",
URL="http://www.rfc-editor.org/rfc/rfc767.txt"
}

@TECHREPORT{rfc768,
AUTHOR="J. B. Postel",
TITLE="User Datagram Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=768,
DAYS=15,
MONTH=aug,
YEAR=1980,
ABSTRACT="The specification of the UDP.",
URL="http://www.rfc-editor.org/rfc/rfc768.txt"
}

@TECHREPORT{rfc769,
AUTHOR="J. B. Postel",
TITLE="Rapicom 450 facsimile file format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=769,
DAYS=15,
MONTH=sep,
YEAR=1980,
ABSTRACT="The definition of the exchange format of the encoded facsimile
data of the Rapicom 450; see also RFC 798.",
URL="http://www.rfc-editor.org/rfc/rfc769.txt"
}

@TECHREPORT{rfc770,
AUTHOR="J. B. Postel",
TITLE="Obsoletes {RFCs:} {762,} {758,} {755,} {750,} {739,} {604,} {503,} {433,}
349 Obsoletes {IENs:} {127,} {117,} 93",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=770,
MONTH=sep,
YEAR=1980,
URL="http://www.rfc-editor.org/rfc/rfc770.txt"
}

@TECHREPORT{rfc771,
AUTHOR="V. G. Cerf and J. B. Postel",
TITLE="Mail transition plan",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=771,
DAYS=15,
MONTH=sep,
YEAR=1980,
ABSTRACT="A plan for supporting mail service in the transition from NCP
to TCP; see also RFC 801.",
URL="http://www.rfc-editor.org/rfc/rfc771.txt"
}

@TECHREPORT{rfc772,
AUTHOR="S. Sluizer and J. B. Postel",
TITLE="Mail Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=772,
DAYS=15,
MONTH=sep,
YEAR=1980,
ABSTRACT="An old version of a Mail Protocol; see RFC 821.",
URL="http://www.rfc-editor.org/rfc/rfc772.txt"
}

@TECHREPORT{rfc773,
AUTHOR="V. G. Cerf",
TITLE="Comments on {NCP/TCP} mail service transition strategy",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=773,
DAYS=15,
MONTH=oct,
YEAR=1980,
ABSTRACT="A discussion of issues in the transition from NCP to TCP,
particularly as related to MAIL Service.",
URL="http://www.rfc-editor.org/rfc/rfc773.txt"
}

@TECHREPORT{rfc774,
AUTHOR="J. B. Postel",
TITLE="Internet Protocol Handbook Table of Contents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=774,
MONTH=oct,
YEAR=1980,
URL="http://www.rfc-editor.org/rfc/rfc774.txt"
}

@TECHREPORT{rfc775,
AUTHOR="D. Mankins and D. Franklin and A. D. Owen",
TITLE="Directory oriented {FTP} commands",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=775,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1980,
ABSTRACT="The definition of additional FTP Commands related to directory
management.",
URL="http://www.rfc-editor.org/rfc/rfc775.txt"
}

@TECHREPORT{rfc776,
AUTHOR="J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=776,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=1981,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc776.txt"
}

@TECHREPORT{rfc777,
AUTHOR="J. B. Postel",
TITLE="Internet Control Message Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=777,
PAGES=14,
DAYS=15,
MONTH=apr,
YEAR=1981,
ABSTRACT="An old version; see RFC 792.",
URL="http://www.rfc-editor.org/rfc/rfc777.txt"
}

@TECHREPORT{rfc778,
AUTHOR="D. L. Mills",
TITLE="{DCNET} Internet Clock Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=778,
DAYS=15,
MONTH=apr,
YEAR=1981,
ABSTRACT="Specifies a format and procedure for the exchange of messages
to maintain synchronized clocks.",
URL="http://www.rfc-editor.org/rfc/rfc778.txt"
}

@TECHREPORT{rfc779,
AUTHOR="E. Killian",
TITLE="Telnet send-location option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=779,
DAYS=15,
MONTH=apr,
YEAR=1981,
ABSTRACT="Definition of this Telnet option.",
URL="http://www.rfc-editor.org/rfc/rfc779.txt"
}

@TECHREPORT{rfc780,
AUTHOR="S. Sluizer and J. B. Postel",
TITLE="Mail Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=780,
PAGES=43,
DAYS=15,
MONTH=may,
YEAR=1981,
ABSTRACT="An outdated Mail protocol; see RFC 821.",
URL="http://www.rfc-editor.org/rfc/rfc780.txt"
}

@TECHREPORT{rfc781,
AUTHOR="Z. Su",
TITLE="Specification of the Internet Protocol {(IP)} timestamp option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=781,
DAYS=15,
MONTH=may,
YEAR=1981,
ABSTRACT="The description of IP Timestamp option, now included in the IP
specification (RFC 791).",
URL="http://www.rfc-editor.org/rfc/rfc781.txt"
}

@TECHREPORT{rfc782,
AUTHOR="J. Nabielsky and A. P. Skelton",
TITLE="Virtual Terminal management model",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=782,
DAYS=15,
MONTH=jan,
YEAR=1981,
ABSTRACT="A description of the elements of a virtual terminal and the
management of communications between them.",
URL="http://www.rfc-editor.org/rfc/rfc782.txt"
}

@TECHREPORT{rfc783,
AUTHOR="Karen Sollins",
TITLE="{TFTP} Protocol (revision {2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=783,
DAYS=15,
MONTH=jun,
YEAR=1981,
ABSTRACT="The specification of TFTP. Replaces RFCs 768, 764 and IEN 133.",
URL="http://www.rfc-editor.org/rfc/rfc783.txt"
}

@TECHREPORT{rfc784,
AUTHOR="S. Sluizer and J. B. Postel",
TITLE="Mail Transfer Protocol: {ISI} {TOPS20} implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=784,
PAGES=62,
DAYS=15,
MONTH=jul,
YEAR=1981,
ABSTRACT="The description of the program structure for the MTP
implementation in the ISI TOPS-20. Outdated.",
URL="http://www.rfc-editor.org/rfc/rfc784.txt"
}

@TECHREPORT{rfc785,
AUTHOR="S. Sluizer and J. B. Postel",
TITLE="Mail Transfer Protocol: {ISI} {TOPS20} file definitions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=785,
PAGES=62,
DAYS=15,
MONTH=jul,
YEAR=1981,
ABSTRACT="The description of the file format for passing mail to the MTP
program from user mail programs in ISI TOPS-20. Outdated.",
URL="http://www.rfc-editor.org/rfc/rfc785.txt"
}

@TECHREPORT{rfc786,
AUTHOR="S. Sluizer and J. B. Postel",
TITLE="Mail Transfer Protocol: {ISI} {TOPS20} {MTP-NIMAIL} interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=786,
PAGES=62,
DAYS=15,
MONTH=jul,
YEAR=1981,
ABSTRACT="The description of the way mail is passed between the MTP and
the NIMAIL programs in ISI TOPS-20. Outdated.",
URL="http://www.rfc-editor.org/rfc/rfc786.txt"
}

@TECHREPORT{rfc787,
AUTHOR="A. Lyman Chapin",
TITLE="Connectionless data transmission survey/tutorial",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=787,
DAYS=15,
MONTH=jul,
YEAR=1981,
ABSTRACT="A discussion of datagram service. Intended for submission to
international standards bodies.",
URL="http://www.rfc-editor.org/rfc/rfc787.txt"
}

@TECHREPORT{rfc788,
AUTHOR="J. B. Postel",
TITLE="Simple Mail Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=788,
PAGES=62,
DAYS=15,
MONTH=nov,
YEAR=1981,
ABSTRACT="An old version; see RFC 821.",
URL="http://www.rfc-editor.org/rfc/rfc788.txt"
}

@TECHREPORT{rfc789,
AUTHOR="E. C. Rosen",
TITLE="Vulnerabilities of network control protocols: An example",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=789,
DAYS=15,
MONTH=jul,
YEAR=1981,
ABSTRACT="A description of an outage in ARPANET service and the process
of determining the cause; also, subtleties of designing network
protocols.",
URL="http://www.rfc-editor.org/rfc/rfc789.txt"
}

@TECHREPORT{rfc790,
AUTHOR="J. B. Postel",
TITLE="Obsoletes {RFCs:} {776,} {770,} {762,} {758,} {755,} {750,} {739,} {604,}
{503,} {433,} 349 Obsoletes {IENs:} {127,} {117,} 93",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=790,
MONTH=sep,
YEAR=1981,
URL="http://www.rfc-editor.org/rfc/rfc790.txt"
}

@TECHREPORT{rfc791,
AUTHOR="J. B. Postel",
TITLE="Internet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=791,
PAGES=45,
DAYS=15,
MONTH=sep,
YEAR=1981,
ABSTRACT="An updated specification of IP. Replaces RFC 760. This
document specifies the DoD Standard Internet Protocol. This document is
based on six earlier editions of the ARPA Internet Protocol
Specification, and the present text draws heavily from them. This
edition revises aspects of addressing, error handling, option codes, and
the security, precedence, compartments, and handling restriction
features of the internet protocol.",
URL="http://www.rfc-editor.org/rfc/rfc791.txt"
}

@TECHREPORT{rfc792,
AUTHOR="John Postel",
TITLE="Internet Control Message Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=792,
MONTH=sep,
YEAR=1981,
KEYWORDS="ICMP",
ABSTRACT="The Internet Protocol (IP) is used for host-to-host datagram
   service in a system of interconnected networks called the
   Catenet.  The network connecting devices are called Gateways.
   These gateways communicate between themselves for control purposes
   via a Gateway to Gateway Protocol (GGP).  Occasionally a
   gateway or destination host will communicate with a source host, for
   example, to report an error in datagram processing.  For such
   purposes this protocol, the Internet Control Message Protocol (ICMP),
   is used.  ICMP, uses the basic support of IP as if it were a higher
   level protocol, however, ICMP is actually an integral part of IP, and
   must be implemented by every IP module.",
URL="http://www.rfc-editor.org/rfc/rfc792.txt"
}

@TECHREPORT{rfc793,
AUTHOR="J. B. Postel",
TITLE="Transmission Control Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=793,
PAGES=85,
DAYS=15,
MONTH=sep,
YEAR=1981,
ABSTRACT="The specification of TCP. Replaces RFCs 761 and 675. This
document describes the DoD Standard Transmission Control Protocol (TCP).
There have been nine earlier editions of the ARPA TCP specification on
which this standard is based, and the present text draws heavily from
them. There have been many contributors to this work both in terms of
concepts and in terms of text. This edition clarifies several details
and removes the end-of-letter buffer-size adjustments, and redescribes
the letter mechanism as a push function.",
URL="http://www.rfc-editor.org/rfc/rfc793.txt"
}

@TECHREPORT{rfc794,
AUTHOR="V. G. Cerf",
TITLE="Pre-emption",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=794,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1981,
ABSTRACT="Discusses how pre-emption of TCP connection can be
implemented. Replaces IEN 125.",
URL="http://www.rfc-editor.org/rfc/rfc794.txt"
}

@TECHREPORT{rfc795,
AUTHOR="J. B. Postel",
TITLE="Service mappings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=795,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1981,
ABSTRACT="A description of how the internet type of service is mapped
into the actual service parameters of a few particular networks, and
vice versa.",
URL="http://www.rfc-editor.org/rfc/rfc795.txt"
}

@TECHREPORT{rfc796,
AUTHOR="J. B. Postel",
TITLE="Address mappings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=796,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=1981,
ABSTRACT="A description of the way the addresses of a few actual
networks are mapped into internet addresses.",
URL="http://www.rfc-editor.org/rfc/rfc796.txt"
}

@TECHREPORT{rfc797,
AUTHOR="A. R. Katz",
TITLE="Format for Bitmap files",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=797,
DAYS=15,
MONTH=sep,
YEAR=1981,
ABSTRACT="The description of a simple file format for bitmap data.",
URL="http://www.rfc-editor.org/rfc/rfc797.txt"
}

@TECHREPORT{rfc798,
AUTHOR="A. R. Katz",
TITLE="Decoding facsimile data from the Rapicom 450",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=798,
DAYS=15,
MONTH=sep,
YEAR=1981,
ABSTRACT="A description of the encoding/decoding procedure for Rapicom
450 facsimile machine.",
URL="http://www.rfc-editor.org/rfc/rfc798.txt"
}

@TECHREPORT{rfc799,
AUTHOR="D. L. Mills",
TITLE="Internet name domains",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=799,
DAYS=15,
MONTH=sep,
YEAR=1981,
ABSTRACT="This document suggests that, as the Internet grows, the space
of host names cannot remain a flat space of globally unique names,
therefore a hierarchy of name domains must be introduced; see also RFC
822.",
URL="http://www.rfc-editor.org/rfc/rfc799.txt"
}

@TECHREPORT{rfc801,
AUTHOR="J. B. Postel",
TITLE="{NCP/TCP} transition plan",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=801,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=1981,
ABSTRACT="This RFC discusses the conversion of hosts from NCP to TCP.
And making available the principle services: Telnet, File Transfer, and
Mail. These protocols allow all hosts in the ARPA community to share a
common interprocess communication environment.",
URL="http://www.rfc-editor.org/rfc/rfc801.txt"
}

@TECHREPORT{rfc802,
AUTHOR="Andrew G. Malis",
TITLE="{ARPANET} {1822L} Host Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=802,
DAYS=15,
MONTH=nov,
YEAR=1981,
ABSTRACT="This document proposed two major changes to the current
ARPANET host access protocol. The first change will allow hosts to use
logical addressing (i.e., host addresses that are independent of their
physical location on the ARPANET) to communicate with each other, and
the second will allow a host to shorten the amount of time that it may
be blocked by its IMP after it presents a message to the network
(currently, the IMP can block further input from a host for up to 15
seconds). See RFCs 852 and 851.",
URL="http://www.rfc-editor.org/rfc/rfc802.txt"
}

@TECHREPORT{rfc803,
AUTHOR="A. Agarwal and M. J. O'Connor and D. L. Mills",
TITLE="Dacom {450/500} facsimile data transcoding",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=803,
DAYS=15,
MONTH=nov,
YEAR=1981,
ABSTRACT="The first part of this RFC describes in detail the Dacom 450
data compression algorithms and is an update and correction to an
earlier memorandum. The second part of this RFC describes briefly the
Dacom 500 data compression algorithm as used by the INTELPOST
electronic-mail network under development by the US Postal Service and
several foreign administrators.",
URL="http://www.rfc-editor.org/rfc/rfc803.txt"
}

@TECHREPORT{rfc804,
AUTHOR="International Telegraph and  ",
TITLE="{CCITT} draft recommendation {T.4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=804,
DAYS=15,
MONTH=jan,
YEAR=1981,
ABSTRACT="This is the CCITT standard for group 3 facsimile encoding.
This is useful for data compression of bit map data.",
URL="http://www.rfc-editor.org/rfc/rfc804.txt"
}

@TECHREPORT{rfc806,
AUTHOR=" {{National Bureau of Standards}}",
TITLE="Proposed Federal Information Processing Standard: Specification for message
format for computer based message systems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=806,
MONTH=sep,
YEAR=1981,
ABSTRACT="This RFC deals with Computer Based Message systems which
provides a basis for interaction between different CBMS by defining the
format of messages passed between them. This RFC is replaced by RFC 841.",
URL="http://www.rfc-editor.org/rfc/rfc806.txt"
}

@TECHREPORT{rfc699,
AUTHOR="J. B. Postel and J. Vernon",
TITLE="Request For Comments summary notes: {600-699}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=699,
DAYS=15,
MONTH=nov,
YEAR=1982,
ABSTRACT="A summary of the Request for Comments documents from RFC
600-699.",
URL="http://www.rfc-editor.org/rfc/rfc699.txt"
}

@TECHREPORT{rfc800,
AUTHOR="J. B. Postel and J. Vernon",
TITLE="Request For Comments summary notes: {700-799}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=800,
DAYS=15,
MONTH=nov,
YEAR=1982,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
700 through RFC 799. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc800.txt"
}

@TECHREPORT{rfc805,
AUTHOR="J. B. Postel",
TITLE="Computer mail meeting notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=805,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1982,
ABSTRACT={This RFC consists of notes from a meeting that was held at
USC/Information Sciences Institute on 11 January 1982, to discuss
addressing issues in computer mail. The major conclusion reached at the
meeting is to extend the {"}username(at)hostname{"} mailbox format to
{"}username(at)host.domain{"}, where the domain itself can be further
structured.},
URL="http://www.rfc-editor.org/rfc/rfc805.txt"
}

@TECHREPORT{rfc807,
AUTHOR="J. B. Postel",
TITLE="Multimedia mail meeting notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=807,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1982,
ABSTRACT="This RFC consists of notes from a meeting held at
USC/Information Sciences Institute on the 12th of January to discuss
common interests in multimedia computer mail issues and to agree on some
specific initial experiments.",
URL="http://www.rfc-editor.org/rfc/rfc807.txt"
}

@TECHREPORT{rfc808,
AUTHOR="J. B. Postel",
TITLE="Summary of computer mail services meeting held at {BBN} on 10 January 1979",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=808,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1982,
ABSTRACT="This RFC is a very belated attempt to document a meeting that
was held three years earlier to discuss the state of computer mail in
the ARPA community and to reach some conclusions to guide the further
development of computer mail systems such that a coherent total mail
service would continue to be provided.",
URL="http://www.rfc-editor.org/rfc/rfc808.txt"
}

@TECHREPORT{rfc809,
AUTHOR="T. Chang",
TITLE="{UCL} facsimile system",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=809,
DAYS=15,
MONTH=feb,
YEAR=1982,
ABSTRACT="This RFC describes the features of the computerised facsimile
system developed in the Department of Computer Science at UCL. First its
functions are considered and the related experimental work are reported.
Then the disciplines for system design are discussed. Finally, the
implementation of the system are described, while detailed description
are given as appendices.",
URL="http://www.rfc-editor.org/rfc/rfc809.txt"
}

@TECHREPORT{rfc810,
AUTHOR="Elizabeth J. Feinler and K. Harrenstien and Z. Su and V. White",
TITLE="{DoD} Internet host table specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=810,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1982,
ABSTRACT="This RFC specifies a new host table format applicable to both
ARPANET and Internet needs. In addition to host name to host address
translation and selected protocol information, we have also included
network and gateway name to address correspondence, and host operating
system information. This RFC obsoletes the host table described in RFC
608.",
URL="http://www.rfc-editor.org/rfc/rfc810.txt"
}

@TECHREPORT{rfc811,
AUTHOR="K. Harrenstien and V. White and Elizabeth J. Feinler",
TITLE="Hostnames Server",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=811,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1982,
ABSTRACT="This RFC gives a description of what the Hostnames Server is
and how to access it. The function of this particular server is to
deliver machine-readable name/address information describing networks,
gateways, hosts, and eventually domains, within the Internet
environment.",
URL="http://www.rfc-editor.org/rfc/rfc811.txt"
}

@TECHREPORT{rfc812,
AUTHOR="K. Harrenstien and V. White",
TITLE="{NICNAME/WHOIS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=812,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1982,
ABSTRACT="This RFC gives a description of what the NICNAME/WHOIS Server
is and how to access it. This server together with the corresponding
Identification Data Base provides online directory look-up equivalent to
the ARPANET Directory.",
URL="http://www.rfc-editor.org/rfc/rfc812.txt"
}

@TECHREPORT{rfc813,
AUTHOR="D. D. Clark",
TITLE="Window and Acknowledgement Strategy in {TCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=813,
DAYS=15,
MONTH=jul,
YEAR=1982,
ABSTRACT="This RFC describes implementation strategies to deal with two
mechanisms in TCP, the window and the acknowledgement. It also presents
a particular set of algorithms which have received testing in the field,
and which appear to work properly with each other. With more experience,
these algorithms may become part of the formal specification, until such
time their use is recommended.",
URL="http://www.rfc-editor.org/rfc/rfc813.txt"
}

@TECHREPORT{rfc814,
AUTHOR="D. D. Clark",
TITLE="Name, addresses, ports, and routes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=814,
DAYS=15,
MONTH=jul,
YEAR=1982,
ABSTRACT="This RFC gives suggestions and guidance for the design of the
tables and algorithms necessary to keep track of these various sorts of
identifiers inside a host implementation of TCP/IP.",
URL="http://www.rfc-editor.org/rfc/rfc814.txt"
}

@TECHREPORT{rfc815,
AUTHOR="D. D. Clark",
TITLE="{IP} datagram reassembly algorithms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=815,
DAYS=15,
MONTH=jul,
YEAR=1982,
ABSTRACT="This RFC describes an alternate approach of dealing with
reassembly which reduces the bookkeeping problem to a minimum, and
requires only one buffer for storage equal in size to the final datagram
being reassembled, which can reassemble a datagram from any number of
fragments arriving in any order with any possible pattern of overlap and
duplication, and which is appropriate for almost any sort of operating
system.",
URL="http://www.rfc-editor.org/rfc/rfc815.txt"
}

@TECHREPORT{rfc816,
AUTHOR="D. D. Clark",
TITLE="Fault isolation and recovery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=816,
DAYS=15,
MONTH=jul,
YEAR=1982,
ABSTRACT="This RFC describes the portion of fault isolation and recovery
which is the responsibility of the host.",
URL="http://www.rfc-editor.org/rfc/rfc816.txt"
}

@TECHREPORT{rfc817,
AUTHOR="D. D. Clark",
TITLE="Modularity and efficiency in protocol implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=817,
DAYS=15,
MONTH=jul,
YEAR=1982,
ABSTRACT="This RFC will discuss some of the commonly encountered reasons
why protocol implementations seem to run slowly.",
URL="http://www.rfc-editor.org/rfc/rfc817.txt"
}

@TECHREPORT{rfc818,
AUTHOR="J. B. Postel",
TITLE="Remote User Telnet service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=818,
PAGES=2,
DAYS=15,
MONTH=nov,
YEAR=1982,
ABSTRACT="This RFC is the specification of an application protocol. Any
host that implements this application level service must follow this
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc818.txt"
}

@TECHREPORT{rfc819,
AUTHOR="Z. Su and J. B. Postel",
TITLE="Domain naming convention for Internet user applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=819,
PAGES=18,
DAYS=15,
MONTH=aug,
YEAR=1982,
ABSTRACT="This RFC is an attempt to clarify the generalization of the
Domain Naming Convention, the Internet Naming Convention, and to explore
the implications of its adoption for ARPA-Internet name service and user
applications.",
URL="http://www.rfc-editor.org/rfc/rfc819.txt"
}

@TECHREPORT{rfc820,
AUTHOR="J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=820,
PAGES=22,
DAYS=15,
MONTH=aug,
YEAR=1982,
ABSTRACT="This RFC is is replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc820.txt"
}

@TECHREPORT{rfc821,
AUTHOR="J. B. Postel",
TITLE="Simple Mail Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=821,
PAGES=68,
DAYS=15,
MONTH=aug,
YEAR=1982,
ABSTRACT="The objective of Simple Mail Transfer Protocol (SMTP) is to
transfer mail reliably and efficiently. SMTP is independent of the
particular transmission subsystem and requires only a reliable ordered
data stream channel. Obsoletes RFCs 788, 780, 772.",
URL="http://www.rfc-editor.org/rfc/rfc821.txt"
}

@TECHREPORT{rfc822,
AUTHOR="D. H. Crocker",
TITLE="Standard for the format of {ARPA} Internet text messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=822,
DAYS=15,
MONTH=aug,
YEAR=1982,
ABSTRACT="This document revises the specifications in RFC 733, in order
to serve the needs of the larger and more complex ARPA-Internet. Some of
RFC 733's features failed to gain adequate acceptance. In order to
simplify the standard and the software that follows it, these features
have been removed. A different addressing scheme is used, to handle the
case of internetwork mail; and the concept of re-transmission has been
introduced. Obsoletes RFC 733, NIC 41952.",
URL="http://www.rfc-editor.org/rfc/rfc822.txt"
}

@TECHREPORT{rfc823,
AUTHOR="Robert Hinden and A. Sheltzer",
TITLE="{DARPA} Internet gateway",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=823,
DAYS=15,
MONTH=sep,
YEAR=1982,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc823.txt"
}

@TECHREPORT{rfc824,
AUTHOR="W. I. MacGregor and D. C. Tappan",
TITLE="{CRONUS} Virtual Local Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=824,
DAYS=15,
MONTH=aug,
YEAR=1982,
ABSTRACT="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 ARPA-Internet Standard.",
URL="http://www.rfc-editor.org/rfc/rfc824.txt"
}

@TECHREPORT{rfc825,
AUTHOR="J. B. Postel",
TITLE="Request for comments on Requests For Comments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=825,
PAGES=2,
DAYS=15,
MONTH=nov,
YEAR=1982,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc825.txt"
}

@TECHREPORT{rfc826,
AUTHOR="D. C. Plummer",
TITLE="Ethernet Address Resolution Protocol: Or converting network protocol
addresses to 48.bit Ethernet address for transmission on Ethernet hardware",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=826,
DAYS=15,
MONTH=nov,
YEAR=1982,
ABSTRACT="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 an 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 an ARPA-Internet Standard.",
URL="http://www.rfc-editor.org/rfc/rfc826.txt"
}

@TECHREPORT{rfc827,
AUTHOR="E. C. Rosen",
TITLE="Exterior Gateway Protocol {(EGP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=827,
DAYS=15,
MONTH=oct,
YEAR=1982,
ABSTRACT="This RFC 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.",
URL="http://www.rfc-editor.org/rfc/rfc827.txt"
}

@TECHREPORT{rfc828,
AUTHOR="K. Owen",
TITLE={Data communications: {IFIP's} international {"}network{"} of experts},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=828,
DAYS=15,
MONTH=aug,
YEAR=1982,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc828.txt"
}

@TECHREPORT{rfc829,
AUTHOR="V. G. Cerf",
TITLE="Packet satellite technology reference sources",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=829,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=1982,
ABSTRACT="This RFC 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
bibliography of relevant papers for researchers interested in
experimental and operational experience with this dynamic
satellite-sharing technique.",
URL="http://www.rfc-editor.org/rfc/rfc829.txt"
}

@TECHREPORT{rfc830,
AUTHOR="Z. Su",
TITLE="Distributed system for Internet name service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=830,
DAYS=15,
MONTH=oct,
YEAR=1982,
ABSTRACT="This RFC proposes a distributed name service for
ARPA-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.",
URL="http://www.rfc-editor.org/rfc/rfc830.txt"
}

@TECHREPORT{rfc831,
AUTHOR="R. Braden",
TITLE="Backup access to the European side of {SATNET}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=831,
DAYS=15,
MONTH=dec,
YEAR=1982,
ABSTRACT="The purpose of this RFC is to focus discussion on a particular
Internet problem: a backup path for software maintenance of the European
sector of the Internet, for use when SATNET is partitioned. We propose a
mechanism, based upon the Source Routing option of IP, to reach European
Internet sites via the VAN Gateway and UCL. This proposal is not
intended as a standard at this time.",
URL="http://www.rfc-editor.org/rfc/rfc831.txt"
}

@TECHREPORT{rfc832,
AUTHOR="D. Smallberg",
TITLE="Who talks {TCP?}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=832,
PAGES=13,
DAYS=15,
MONTH=dec,
YEAR=1982,
ABSTRACT="This RFC is a survey of hosts to identify the implementation
status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from
the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82.",
URL="http://www.rfc-editor.org/rfc/rfc832.txt"
}

@TECHREPORT{rfc871,
AUTHOR="M. A. Padlipsky",
TITLE="Perspective on the {ARPANET} reference model",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=871,
DAYS=15,
MONTH=sep,
YEAR=1982,
ABSTRACT="This RFC is primarily intended as a perspective on the ARM and
points out some of the differences between the ARM and the ISORM which
were expressed by members in NWG general meetings, NWG protocol design
committee meetings, the ARPA-Internet Working Group, and private
conversations over the intervening years. Originally published as M82-47
by the MITRE Corporation, Bedford, Massachusetts.",
URL="http://www.rfc-editor.org/rfc/rfc871.txt"
}

@TECHREPORT{rfc872,
AUTHOR="M. A. Padlipsky",
TITLE="{TCP-on-a-LAN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=872,
DAYS=15,
MONTH=sep,
YEAR=1982,
ABSTRACT="This memo attacks the notion that TCP cannot be appropriate
for use on a Local Area Network. Originally published as M82-48 by the
MITRE Corporation, Bedford Massachusetts.",
URL="http://www.rfc-editor.org/rfc/rfc872.txt"
}

@TECHREPORT{rfc873,
AUTHOR="M. A. Padlipsky",
TITLE="Illusion of vendor support",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=873,
DAYS=15,
MONTH=sep,
YEAR=1982,
ABSTRACT="This memo takes issue with the claim that international
standards in computer protocols presently provide a basis for low cost
vendor supported protocol implementations. Originally published as
M82-49 by the MITRE Corporation, Bedford, Massachusetts.",
URL="http://www.rfc-editor.org/rfc/rfc873.txt"
}

@TECHREPORT{rfc874,
AUTHOR="M. A. Padlipsky",
TITLE="Critique of {X.25}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=874,
DAYS=15,
MONTH=sep,
YEAR=1982,
ABSTRACT="This RFC is an analysis of X.25 pointing out some problems in
the conceptual model, particularly the conflict between the interface
aspects and the end-to-end aspects. The memo also touches on security,
and implementation issues. Originally published as M82-50 by the MITRE
Corporation, Bedford, Massachusetts.",
URL="http://www.rfc-editor.org/rfc/rfc874.txt"
}

@TECHREPORT{rfc875,
AUTHOR="M. A. Padlipsky",
TITLE="Gateways, architectures, and heffalumps",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=875,
DAYS=15,
MONTH=sep,
YEAR=1982,
ABSTRACT={This RFC is a discussion about the role of gateways in an
internetwork, especially the problems of translating or mapping
protocols between different protocol suites. The discussion notes
possible functionality mis-matches, undesirable routing {"}singularity
points{"}, flow control issues, and high cost of translating gateways.
Originally published as M82-51 by the MITRE Corporation, Bedford,
Massachusetts.},
URL="http://www.rfc-editor.org/rfc/rfc875.txt"
}

@TECHREPORT{rfc836,
AUTHOR="D. Smallberg",
TITLE="Who talks {TCP?}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=836,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=1983,
ABSTRACT="This RFC is a survey of hosts to identify the implementation
status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from
the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83
through 5-Jan-83.",
URL="http://www.rfc-editor.org/rfc/rfc836.txt"
}

@TECHREPORT{rfc840,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Official protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=840,
PAGES=23,
DAYS=15,
MONTH=apr,
YEAR=1983,
ABSTRACT="This RFC has been replaced by RFC 991.",
URL="http://www.rfc-editor.org/rfc/rfc840.txt"
}

@TECHREPORT{rfc841,
AUTHOR=" {{National Bureau of Standards}}",
TITLE="Specification for message format for Computer Based Message Systems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=841,
MONTH=jan,
YEAR=1983,
ABSTRACT="This RFC is FIPS 98. The purpose of distributing this document
as an RFC is to make it easily accessible to the ARPA research
community. This RFC does not specify a standard for the ARPA-Internet.
Obsoletes RFC 806.",
URL="http://www.rfc-editor.org/rfc/rfc841.txt"
}

@TECHREPORT{rfc842,
AUTHOR="D. Smallberg",
TITLE="Who talks {TCP?} - survey of 1 February 83",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=842,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=1983,
ABSTRACT="This RFC is a survey of hosts to identify the implementation
status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from
the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and
on 2-Feb-83 ISI-VAXA.ARPA.",
URL="http://www.rfc-editor.org/rfc/rfc842.txt"
}

@TECHREPORT{rfc843,
AUTHOR="D. Smallberg",
TITLE="Who talks {TCP?} - survey of 8 February 83",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=843,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=1983,
ABSTRACT="This RFC is a survey of hosts to identify the implementation
status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from
the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and
on 9-Feb-83 from ISI-VAXA.ARPA.",
URL="http://www.rfc-editor.org/rfc/rfc843.txt"
}

@TECHREPORT{rfc844,
AUTHOR="R. Clements",
TITLE="Who talks {ICMP,} too? - Survey of 18 February 1983",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=844,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=1983,
ABSTRACT="This survey determines 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. The list of hosts was taken from RFC 843,
extracting only those hosts which are listed there as accepting Telnet
connection. The tests were run on 18-Feb-83.",
URL="http://www.rfc-editor.org/rfc/rfc844.txt"
}

@TECHREPORT{rfc845,
AUTHOR="D. Smallberg",
TITLE="Who talks {TCP?} - survey of 15 February 1983",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=845,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=1983,
ABSTRACT="This RFC is a survey of hosts to identify the implementation
status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from
the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from
ISI-VAXA.ARPA.",
URL="http://www.rfc-editor.org/rfc/rfc845.txt"
}

@TECHREPORT{rfc846,
AUTHOR="D. Smallberg",
TITLE="Who talks {TCP?} - survey of 22 February 1983",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=846,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=1983,
ABSTRACT="This RFC is a survey of hosts to identify the implementation
status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from
the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83
from ISI-VAXA.ARPA.",
URL="http://www.rfc-editor.org/rfc/rfc846.txt"
}

@TECHREPORT{rfc847,
AUTHOR="A. Westine and D. Smallberg and J. B. Postel",
TITLE="Summary of Smallberg surveys",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=847,
PAGES=2,
DAYS=15,
MONTH=feb,
YEAR=1983,
ABSTRACT="This is a summary of the surveys of Telnet, FTP and Mail
(SMTP) servers conducted by David Smallberg in December 1982, 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 ARPA-Internet (not counting TACs or ECHOS).",
URL="http://www.rfc-editor.org/rfc/rfc847.txt"
}

@TECHREPORT{rfc848,
AUTHOR="D. Smallberg",
TITLE={Who provides the {"}little{"} {TCP} services?},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=848,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1983,
ABSTRACT={This RFC lists those hosts which provide any of these {"}little{"}
TCP services: The list of hosts were taken from the NIC hostname table
of 24-Feb-83. The tests were run on February 23 and 24, and March 3 and
5 from ISI-VAXA.ARPA.},
URL="http://www.rfc-editor.org/rfc/rfc848.txt"
}

@TECHREPORT{rfc849,
AUTHOR="M. R. Crispin",
TITLE="Suggestions for improved host table distribution",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=849,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This RFC 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.",
URL="http://www.rfc-editor.org/rfc/rfc849.txt"
}

@TECHREPORT{rfc850,
AUTHOR="M. R. Horton",
TITLE="Standard for interchange of {USENET} messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=850,
DAYS=15,
MONTH=jun,
YEAR=1983,
ABSTRACT="This memo is distributed as an RFC only to make this
information easily accessible to researchers in the ARPA-Internet
community. It does not specify an Internet standard. This RFC defines
the standard format for interchange of Network News articles among
USENET sites. It describes the format for articles themselves, and gives
partial standards for transmission of news. The news transmission is not
entirely standardized in order to give a good deal of flexibility to the
individual hosts to choose transmission hardware and software, whether
to batch news and so on.",
URL="http://www.rfc-editor.org/rfc/rfc850.txt"
}

@TECHREPORT{rfc851,
AUTHOR="Andrew G. Malis",
TITLE="{ARPANET} {1822L} Host Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=851,
DAYS=15,
MONTH=apr,
YEAR=1983,
ABSTRACT="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. This RFC is also being presented
as a solicitation of comments on 1822L, especially from host network
software implementers and maintainers. Obsoletes RFC 802.",
URL="http://www.rfc-editor.org/rfc/rfc851.txt"
}

@TECHREPORT{rfc852,
AUTHOR="Andrew G. Malis",
TITLE="{ARPANET} short blocking feature",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=852,
DAYS=15,
MONTH=apr,
YEAR=1983,
ABSTRACT="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. This RFC is also
being presented as a solicitation of comments on the Short Blocking
Feature, especially from host network software implementers and
maintainers.",
URL="http://www.rfc-editor.org/rfc/rfc852.txt"
}

@TECHREPORT{rfc854,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Telnet Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=854,
PAGES=15,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT={This is the specification of the Telnet protocol used for
remote terminal access in the ARPA-Internet. The purpose of the Telnet
Protocol is to provide a fairly general, bi-directional, eight-bit byte
oriented communications facility. Its primary goal is to allow a
standard method of interfacing terminal devices and terminal-oriented
processes to each other. It is envisioned that the protocol may also be
used for terminal-terminal communication ({"}linking{"}) and
process-process
communication (distributed computation). This RFC specifies a standard
for the ARPA-Internet community. Hosts on the ARPA-Internet are expected
to adopt and implement this standard. Obsoletes NIC 18639.},
URL="http://www.rfc-editor.org/rfc/rfc854.txt"
}

@TECHREPORT{rfc855,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Telnet Option Specifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=855,
PAGES=3,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This memo specifies the general form for Telnet options and
the directions for their specification. This RFC specifies a standard
for the ARPA-Internet community. Hosts on the ARPA-Internet are expected
to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.",
URL="http://www.rfc-editor.org/rfc/rfc855.txt"
}

@TECHREPORT{rfc856,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Telnet Binary Transmission",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=856,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This Telnet Option enables a binary data mode between the
Telnet modules. This RFC specifies a standard for the ARPA-Internet
community. Hosts on the ARPA-Internet are expected to adopt and
implement this standard. Obsoletes NIC 15389.",
URL="http://www.rfc-editor.org/rfc/rfc856.txt"
}

@TECHREPORT{rfc857,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Telnet Echo Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=857,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This Telnet Option enables remote echoing by the other Telnet
module. This RFC specifies a standard for the ARPA-Internet community.
Hosts on the ARPA-Internet are expected to adopt and implement this
standard. Obsoletes NIC 15390.",
URL="http://www.rfc-editor.org/rfc/rfc857.txt"
}

@TECHREPORT{rfc858,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Telnet Suppress Go Ahead Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=858,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This Telnet Option disables the exchange of go-ahead signals
between the Telnet modules. This RFC specifies a standard for the
ARPA-Internet community. Hosts on the ARPA-Internet are expected to
adopt and implement this standard. Obsoletes NIC 15392.",
URL="http://www.rfc-editor.org/rfc/rfc858.txt"
}

@TECHREPORT{rfc859,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Telnet Status Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=859,
PAGES=3,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This Telnet Option provides a way to determine the other
Telnet module's view of the status of options. This RFC specifies a
standard for the ARPA-Internet community. Hosts on the ARPA-Internet are
expected to adopt and implement this standard. Obsoletes RFC 651 (NIC
31154).",
URL="http://www.rfc-editor.org/rfc/rfc859.txt"
}

@TECHREPORT{rfc860,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Telnet Timing Mark Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=860,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This Telnet Option provides a way to check the roundtrip path
between two Telnet modules. This RFC specifies a standard for the
ARPA-Internet community. Hosts on the ARPA-Internet are expected to
adopt and implement this standard. Obsoletes NIC 16238.",
URL="http://www.rfc-editor.org/rfc/rfc860.txt"
}

@TECHREPORT{rfc861,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Telnet Extended Options: List Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=861,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This Telnet Option provides a mechanism for extending the set
of possible options. This RFC specifies a standard for the ARPA-Internet
community. Hosts on the ARPA-Internet are expected to adopt and
implement this standard. Obsoletes NIC 16239.",
URL="http://www.rfc-editor.org/rfc/rfc861.txt"
}

@TECHREPORT{rfc862,
AUTHOR="J. B. Postel",
TITLE="Echo Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=862,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="This RFC specifies a standard for the ARPA-Internet community.
Hosts on the ARPA-Internet that choose to implement a Echo Protocol are
expected to adopt and implement this standard. The Echo service simply
sends back to the originating source any data it receives.",
URL="http://www.rfc-editor.org/rfc/rfc862.txt"
}

@TECHREPORT{rfc863,
AUTHOR="J. B. Postel",
TITLE="Discard Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=863,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="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. The Discard service
simply throws away any data it receives.",
URL="http://www.rfc-editor.org/rfc/rfc863.txt"
}

@TECHREPORT{rfc864,
AUTHOR="J. B. Postel",
TITLE="Character Generator Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=864,
PAGES=3,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="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.
The Character Generator service simply sends data without regard to the
input.",
URL="http://www.rfc-editor.org/rfc/rfc864.txt"
}

@TECHREPORT{rfc865,
AUTHOR="J. B. Postel",
TITLE="Quote of the Day Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=865,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="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. The Quote of
the Day service simply sends a short message without regard to the
input.",
URL="http://www.rfc-editor.org/rfc/rfc865.txt"
}

@TECHREPORT{rfc866,
AUTHOR="J. B. Postel",
TITLE="Active users",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=866,
PAGES=1,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="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. The Active
Users service simply sends a list of the currently active users on the
host without regard to the input.",
URL="http://www.rfc-editor.org/rfc/rfc866.txt"
}

@TECHREPORT{rfc867,
AUTHOR="J. B. Postel",
TITLE="Daytime Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=867,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="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. The Daytime service
simply sends the current date and time as a character string without
regard to the input.",
URL="http://www.rfc-editor.org/rfc/rfc867.txt"
}

@TECHREPORT{rfc868,
AUTHOR="J. B. Postel and K. Harrenstien",
TITLE="Time Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=868,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1983,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc868.txt"
}

@TECHREPORT{rfc869,
AUTHOR="R. Hinden",
TITLE="Host Monitoring Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=869,
DAYS=15,
MONTH=dec,
YEAR=1983,
ABSTRACT="This RFC specifies the Host Monitoring Protocol used to
collect information from various types of hosts in the Internet.
Designers of Internet communications software are encouraged to consider
this protocol as a means of monitoring the behavior of their creations.",
URL="http://www.rfc-editor.org/rfc/rfc869.txt"
}

@TECHREPORT{rfc870,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=870,
PAGES=26,
DAYS=15,
MONTH=oct,
YEAR=1983,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc870.txt"
}

@TECHREPORT{rfc876,
AUTHOR="D. Smallberg",
TITLE="Survey of {SMTP} implementations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=876,
PAGES=13,
DAYS=15,
MONTH=sep,
YEAR=1983,
ABSTRACT="This RFC is a survey of implementation status. It does not
specify an official protocol, but rather notes the status of
implementation 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 implemetations.",
URL="http://www.rfc-editor.org/rfc/rfc876.txt"
}

@TECHREPORT{rfc877,
AUTHOR="John T. Korb",
TITLE="Standard for the transmission of {IP} datagrams over public data networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=877,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1983,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc877.txt"
}

@TECHREPORT{rfc879,
AUTHOR="J. B. Postel",
TITLE="{TCP} maximum segment size and related topics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=879,
PAGES=11,
DAYS=15,
MONTH=nov,
YEAR=1983,
ABSTRACT={This RFC discusses the TCP Maximum Segment Size Option and
related topics. The purpose 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{"}.},
URL="http://www.rfc-editor.org/rfc/rfc879.txt"
}

@TECHREPORT{rfc881,
AUTHOR="J. B. Postel",
TITLE="Domain names plan and schedule",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=881,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1983,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc881.txt"
}

@TECHREPORT{rfc882,
AUTHOR="P. V. Mockapetris",
TITLE="Domain names: Concepts and facilities",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=882,
PAGES=31,
DAYS=15,
MONTH=nov,
YEAR=1983,
ABSTRACT="This RFC introduces domain style names, their use for
DDN/ARPA-Internet mail and host address support, and the protocol and
servers used to implement domain name facilities.",
URL="http://www.rfc-editor.org/rfc/rfc882.txt"
}

@TECHREPORT{rfc883,
AUTHOR="P. V. Mockapetris",
TITLE="Domain names: Implementation specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=883,
PAGES=73,
DAYS=15,
MONTH=nov,
YEAR=1983,
ABSTRACT="This RFC 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.",
URL="http://www.rfc-editor.org/rfc/rfc883.txt"
}

@TECHREPORT{rfc884,
AUTHOR="M. Solomon and E. Wimmers",
TITLE="Telnet terminal type option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=884,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1983,
ABSTRACT="This RFC specifies a standard for the ARPA-Internet community.
It specifies a method for exchanging terminal type information in the
Telnet protocol.",
URL="http://www.rfc-editor.org/rfc/rfc884.txt"
}

@TECHREPORT{rfc885,
AUTHOR="J. B. Postel",
TITLE="Telnet end of record option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=885,
PAGES=2,
DAYS=15,
MONTH=dec,
YEAR=1983,
ABSTRACT="This RFC specifies a standard for the ARPA-Internet community.
It specifies a method for marking the end of records in data transmitted
on Telnet connections.",
URL="http://www.rfc-editor.org/rfc/rfc885.txt"
}

@TECHREPORT{rfc886,
AUTHOR="Marshall T. Rose",
TITLE="Proposed standard for message header munging",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=886,
PAGES=16,
DAYS=15,
MONTH=dec,
YEAR=1983,
ABSTRACT="This RFC specifies a draft standard for the ARPA-Internet
community. It describes the rules to be used when transforming mail from
the conventions of one message system to those of another message
system. In particular, the treatment of header fields, and recipient
addresses is specified.",
URL="http://www.rfc-editor.org/rfc/rfc886.txt"
}

@TECHREPORT{rfc887,
AUTHOR="M. J. Accetta",
TITLE="Resource Location Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=887,
PAGES=16,
DAYS=15,
MONTH=dec,
YEAR=1983,
ABSTRACT="This RFC specifies a draft standard for the ARPA-Internet
community. It 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
ARPA-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 ARPA-Internet.",
URL="http://www.rfc-editor.org/rfc/rfc887.txt"
}

@TECHREPORT{rfc889,
AUTHOR="D. L. Mills",
TITLE="Internet delay experiments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=889,
DAYS=15,
MONTH=dec,
YEAR=1983,
ABSTRACT="This memo reports on some measurements of round-trip times in
the Internet and suggests some possible improvements to the TCP
retransmission timeout calculation. This memo is both a status report on
the ARPA-Internet and advice to TCP implementers.",
URL="http://www.rfc-editor.org/rfc/rfc889.txt"
}

@TECHREPORT{rfc891,
AUTHOR="D. L. Mills",
TITLE="{DCN} local-network protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=891,
PAGES=26,
DAYS=15,
MONTH=dec,
YEAR=1983,
ABSTRACT="This RFC provides a description of the DCN protocols for
maintaining connectivity, routing, and clock information in a local
network. These procedures may be of interest to the designers and
implementers of other local networks.",
URL="http://www.rfc-editor.org/rfc/rfc891.txt"
}

@TECHREPORT{rfc892,
AUTHOR=" {{International Organization for Standardization}}",
TITLE="{ISO} Transport Protocol specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=892,
MONTH=dec,
YEAR=1983,
ABSTRACT="This is a draft version of the transport protocol being
standardized by the ISO. This version also appeared in the ACM SIGCOMM
Computer Communication Review (V.12, N.3-4) July-October 1982. This
version is now out of date.",
URL="http://www.rfc-editor.org/rfc/rfc892.txt"
}

@TECHREPORT{rfc888,
AUTHOR="L. Seamonson and E. C. Rosen",
TITLE={{{"}STUB{"}} Exterior Gateway Protocol},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=888,
DAYS=15,
MONTH=jan,
YEAR=1984,
ABSTRACT="This RFC describes the Exterior Gateway Protocol (EGP) 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.",
URL="http://www.rfc-editor.org/rfc/rfc888.txt"
}

@TECHREPORT{rfc890,
AUTHOR="J. B. Postel",
TITLE="Exterior Gateway Protocol implementation schedule",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=890,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1984,
ABSTRACT="This memo is a policy statement on the implementation of the
Exterior Gateway Protocol (EGP) in the ARPA-Internet. This is an
official policy statement of ICCB and DARPA. After 1-Aug-84 there shall
be no dumb gateways in the Internet. Every gateway must be a member of
some autonomous system. Some gateway of each autonomous system must
exchange routing information with some gateway of the core autonomous
system using the Exterior Gateway Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc890.txt"
}

@TECHREPORT{rfc893,
AUTHOR="S. Leffler and Mike Karels",
TITLE="Trailer encapsulations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=893,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1984,
ABSTRACT={This RFC discusses the motivation for use of {"}trailer
encapsulations{"} on local-area networks and describes the implementation
of such an encapsulation on various media. This document is for
information only. This is NOT an official protocol for the ARPA-Internet
community.},
URL="http://www.rfc-editor.org/rfc/rfc893.txt"
}

@TECHREPORT{rfc894,
AUTHOR="C. Hornig",
TITLE="Standard for the transmission of {IP} datagrams over Ethernet networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=894,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1984,
ABSTRACT="This RFC specifies a standard method of encapsulating Internet
Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard
protocol for the ARPA-Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc894.txt"
}

@TECHREPORT{rfc895,
AUTHOR="J. B. Postel",
TITLE="Standard for the transmission of {IP} datagrams over experimental Ethernet
networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=895,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1984,
ABSTRACT="This RFC specifies a standard method of encapsulating Internet
Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies
a standard protocol for the ARPA-Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc895.txt"
}

@TECHREPORT{rfc896,
AUTHOR="J. Nagle",
TITLE="Congestion control in {IP/TCP} internetworks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=896,
DAYS=15,
MONTH=jan,
YEAR=1984,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc896.txt"
}

@TECHREPORT{rfc897,
AUTHOR="J. B. Postel",
TITLE="Domain name system implementation schedule",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=897,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=1984,
ABSTRACT="This memo is a policy statement on the implementation of the
Domain Style Naming System in the ARPA-Internet. This memo is a partial
update of RFC 881. The intent of this memo is to detail the schedule for
the implementation of the Domain Style Naming System. The names of hosts
will be changed to Domain style names. Hosts will begin to use Domain
style names on 14-Mar-84, and the use of old style names will be
completely phased out before 2-May-84. This applies to both the ARPA
research hosts and the DDN operational hosts. This is an official policy
statement of the ICCB and the DARPA.",
URL="http://www.rfc-editor.org/rfc/rfc897.txt"
}

@TECHREPORT{rfc898,
AUTHOR="Robert Hinden and J. B. Postel and M. Muuss and J. F. Reynolds",
TITLE="Gateway special interest group meeting notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=898,
PAGES=24,
DAYS=15,
MONTH=apr,
YEAR=1984,
ABSTRACT="This memo is a report on the Gateway Special Interest Group
Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden
of BBNCC chaired, and Jon Postel of ISI hosted the meeting.
Approximately 35 gateway designers and implementors attended. These
notes are based on the recollections of Jon Postel and Mike Muuss. Under
each topic area are Jon Postel's brief notes, and additional details
from Mike Muuss. This memo is a report on the meeting. No conclusions,
decisions, or policy statements are documented in this note.",
URL="http://www.rfc-editor.org/rfc/rfc898.txt"
}

@TECHREPORT{rfc899,
AUTHOR="J. B. Postel and A. Westine",
TITLE="Request For Comments summary notes: {800-899}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=899,
DAYS=15,
MONTH=may,
YEAR=1984,
ABSTRACT="A summary of the Request for Comments documents from RFC
800-898.",
URL="http://www.rfc-editor.org/rfc/rfc899.txt"
}

@TECHREPORT{rfc900,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Assigned Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=900,
PAGES=43,
DAYS=15,
MONTH=jun,
YEAR=1984,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc900.txt"
}

@TECHREPORT{rfc901,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Official {ARPA-Internet} protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=901,
PAGES=28,
DAYS=15,
MONTH=jun,
YEAR=1984,
ABSTRACT="This RFC has been replaced by RFC 991.",
URL="http://www.rfc-editor.org/rfc/rfc901.txt"
}

@TECHREPORT{rfc902,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="{ARPA} Internet Protocol policy",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=902,
PAGES=5,
DAYS=15,
MONTH=jul,
YEAR=1984,
ABSTRACT="The purpose of this memo is to explain how protocol standards
are adopted for the ARPA-Internet and the DARPA research community.
There are three important aspects to be discussed: the process, the
authority, and the complex relationship between the DARPA community and
the DDN community. This memo is a policy statement on how protocols
become official standards for the ARPA-Internet and the DARPA research
community. This is an official policy statement of the ICCB and the
DARPA.",
URL="http://www.rfc-editor.org/rfc/rfc902.txt"
}

@TECHREPORT{rfc903,
AUTHOR="R. Finlayson and T. P. Mann and J. C. Mogul and M. M. Theimer",
TITLE="Reverse Address Resolution Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=903,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=1984,
ABSTRACT="This RFC suggests a method for workstations to dynamically
find their protocol address (e.g., their Internet Address), when they
know only their hardware address (e.g., their attached physical network
address). This RFC specifies a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvement.",
URL="http://www.rfc-editor.org/rfc/rfc903.txt"
}

@TECHREPORT{rfc904,
AUTHOR="D. L. Mills",
TITLE="Exterior Gateway Protocol formal specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=904,
PAGES=30,
DAYS=15,
MONTH=apr,
YEAR=1984,
ABSTRACT="This is the specification of the Exterior Gateway Protocol
(EGP). This memo updates portions of RFC 888 and RFC 827. This RFC
specifies an official protocol of the DARPA community for use between
gateways of different autonomous systems in the ARPA-Internet.",
URL="http://www.rfc-editor.org/rfc/rfc904.txt"
}

@TECHREPORT{rfc905,
AUTHOR="David Hutchison",
TITLE="{ISO} Transport Protocol specification {ISO} {DP} 8073",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=905,
DAYS=15,
MONTH=apr,
YEAR=1984,
ABSTRACT="This is the current specification of the ISO Transport
Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected
by ISO/TC97/SC16/N1695. This is the specification currently being voted
on in ISO as a Draft International Standard (DIS). This document is
distributed as an RFC for your information only, it does not specify a
standard for the ARPA-Internet or DARPA research community. Our thanks
to Alex McKenzie of BBN for making this online version available. Please
note the size of this document, the file contains 258,729 characters.",
URL="http://www.rfc-editor.org/rfc/rfc905.txt"
}

@TECHREPORT{rfc906,
AUTHOR="R. Finlayson",
TITLE="Bootstrap loading using {TFTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=906,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=1984,
ABSTRACT="It is often convenient to be able to bootstrap a computer
system from a communications network. This RFC proposes the use of the
IP/TFTP protocol for bootstrap loading in this case.",
URL="http://www.rfc-editor.org/rfc/rfc906.txt"
}

@TECHREPORT{rfc907,
AUTHOR="Bolt Beranek and Newman Inc",
TITLE="Host Access Protocol specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=907,
PAGES=75,
DAYS=15,
MONTH=jul,
YEAR=1984,
ABSTRACT="This document specifies the Host Access Protocol (HAP).
Although HAP was originally designed as the network-access level
protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network,
it is intended that it evolve into a standard interface SATNET and
TACNET (aka MATNET) as well as the Wideband Network. HAP is an
experimental protocol, and will undergo further revision as new
capabilities are added and/or different satellite networks are suported.
Implementations of HAP should be performed in coordination with
satellite network development and operations personnel.",
URL="http://www.rfc-editor.org/rfc/rfc907.txt"
}

@TECHREPORT{rfc908,
AUTHOR="D. Velten and Robert Hinden and J. Sax",
TITLE="Reliable Data Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=908,
PAGES=57,
DAYS=15,
MONTH=jul,
YEAR=1984,
ABSTRACT="The Reliable Data Protocol (RDP) is designed to provide a
reliable data transport service for packet-based applications. This RFC
specifies a proposed protocol for the ARPA-Internet and DARPA research
community, and requests discussion and suggestions for improvemts.",
URL="http://www.rfc-editor.org/rfc/rfc908.txt"
}

@TECHREPORT{rfc909,
AUTHOR="C. Welles and W. Milliken",
TITLE="Loader Debugger Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=909,
PAGES=128,
DAYS=15,
MONTH=jul,
YEAR=1984,
ABSTRACT="The Loader Debugger Protocol (LDP) is an application layer
protocol for loading, dumping, and debugging target machines from hosts
in a network environment. This RFC specifies a proposed protocol for the
ARPA-Internet and DARPA research community, and requests discussion and
suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc909.txt"
}

@TECHREPORT{rfc910,
AUTHOR="H. C. Forsdick",
TITLE="Multimedia mail meeting notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=910,
PAGES=11,
DAYS=15,
MONTH=aug,
YEAR=1984,
ABSTRACT="This memo is a report on a meeting about the experimental
multimedia mail system (and in a sense a status report on that
experiment). The meeting was held at Bolt Beranek and Newman on 23-24
July 1984 to discuss recent progress by groups who are building
multimedia mail systems and to discuss a variety of issues related to
the further development of multimedia systems. Representatives were
present from BBN, ISI, SRI and Linkabit. Distribution of this memo is
unlimited.",
URL="http://www.rfc-editor.org/rfc/rfc910.txt"
}

@TECHREPORT{rfc911,
AUTHOR="P. Kirton",
TITLE="{EGP} Gateway under Berkeley {UNIX} {4.2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=911,
PAGES=22,
DAYS=15,
MONTH=aug,
YEAR=1984,
ABSTRACT="This memo describes an implementation of the Exterior Gateway
Protocol (EGP) (in that sense it is a status report). The memo also
discusses some possible extentions and some design issues (in that sense
it is an invitation for further discussion).",
URL="http://www.rfc-editor.org/rfc/rfc911.txt"
}

@TECHREPORT{rfc912,
AUTHOR="M. St. Johns",
TITLE="Authentication service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=912,
PAGES=3,
DAYS=15,
MONTH=sep,
YEAR=1984,
ABSTRACT="This memo describes a proposed authentication protocol for
verifying the identity of a user of a TCP connection. Given a TCP port
number pair, it returns a character string which identifies the owner of
that connection on the server's system. Suggested uses include automatic
identification and verification of a user during an FTP session,
additional verification of a TAC dial up user, and access verification
for a generalized network file server.",
URL="http://www.rfc-editor.org/rfc/rfc912.txt"
}

@TECHREPORT{rfc913,
AUTHOR="M. Lottor",
TITLE="Simple File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=913,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=1984,
ABSTRACT="This memo describes a proposed Simple File Transfer Protocol
(SFTP). It fills the need of people wanting a protocol that is more
useful than TFTP but easier to implement (and less powerful) than FTP.
SFTP supports user access control, file transfers, directory listing,
directory changing, file renaming, and deleting. Discussion of this
proposal is encouraged, and suggestions for improvements may be sent to
the author.",
URL="http://www.rfc-editor.org/rfc/rfc913.txt"
}

@TECHREPORT{rfc914,
AUTHOR="D. Farber and G. S. Delp and Thomas M. Conte",
TITLE="Thinwire protocol for connecting personal computers to the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=914,
PAGES=22,
DAYS=15,
MONTH=sep,
YEAR=1984,
ABSTRACT="This document focuses discussion on the particular problems in
the ARPA-Internet of low speed network interconnection with personal
computers, and possible methods of solution. None of the proposed
solutions in this document are intended as standards for the
ARPA-Internet. Rather, it is hoped that a general consensus will emerge
as to the appropriate solution to the problems, leading eventually to
the adoption of standards.",
URL="http://www.rfc-editor.org/rfc/rfc914.txt"
}

@TECHREPORT{rfc915,
AUTHOR="M. A. Elvy and R. Nedved",
TITLE="Network mail path service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=915,
PAGES=11,
DAYS=15,
MONTH=dec,
YEAR=1984,
ABSTRACT="The network mail path service fills the current need of people
to determine mailbox addresses for hosts that are not part of the
ARPA-Internet but can be reached by one or more relay hosts that have
Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail,
etc. Anyone can use the service if they have TCP/TELENET to one of the
hosts with a mail path server. This RFC proposes a new service for the
ARPA-Internet community and requests discussion and suggestions for
improvements.",
URL="http://www.rfc-editor.org/rfc/rfc915.txt"
}

@TECHREPORT{rfc916,
AUTHOR="G. D. Finn",
TITLE="Reliable Asynchronous Transfer Protocol {(RATP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=916,
PAGES=54,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT="This paper proposes and specifies a protocol which allows two
programs to reliably communicate over a communication link. It ensures
that the data entering one end of the link if received arrives at the
other end intact and unaltered. The protocol, named RATP, is designed to
operate over a full duplex point-to-point connection. It contains some
features which tailor it to the RS-232 links now in common use. This RFC
suggests a proposed protocol for the ARPA-Internet community, and
requests discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc916.txt"
}

@TECHREPORT{rfc917,
AUTHOR="J. C. Mogul",
TITLE="Internet subnets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=917,
PAGES=22,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT="This memo discusses subnets and proposes procedures for the
use of subnets, including approaches to solving the problems that arise,
particularly that of routing. A subnet of an Internet network is a
logically visible sub-section of a single Internet network. For
administrative or technical reasons, many organizations have chosen to
divide one Internet network into several subnets, instead of acquiring a
set of Internet network numbers. This RFC suggests a proposed protocol
for the ARPA-Internet community, and requests discussion and suggestions
for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc917.txt"
}

@TECHREPORT{rfc918,
AUTHOR="J. F. Reynolds",
TITLE="Post Office Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=918,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT="Updated by RFC 937.",
URL="http://www.rfc-editor.org/rfc/rfc918.txt"
}

@TECHREPORT{rfc919,
AUTHOR="J. C. Mogul",
TITLE="Broadcasting Internet Datagrams",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=919,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT="This RFC proposes simple rules for broadcasting Internet
datagrams on local networks that support broadcast, for addressing
broadcasts, and for how gateways should handle them. This RFC suggests a
proposed protocol for the ARPA-Internet community, and requests
discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc919.txt"
}

@TECHREPORT{rfc920,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Domain requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=920,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT="This memo states the requirements on establishing a Domain,
and introduces the limited set of top level domains. This memo is a
policy statement on the requirements of establishing a new domain in the
ARPA-Internet and the DARPA research community. This is an official
policy statement of the IAB and the DARPA.",
URL="http://www.rfc-editor.org/rfc/rfc920.txt"
}

@TECHREPORT{rfc921,
AUTHOR="J. B. Postel",
TITLE="Domain name system implementation schedule - revised",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=921,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT="This memo is a policy statement on the implementation of the
Domain Style Naming System in the ARPA-Internet. This memo is an update
of RFC 881, and RFC 897. This is an official policy statement of the IAB
and the DARPA. The intent of this memo is to detail the schedule for the
implementation for the Domain Style Naming System. The explanation of
how this system works is to be found in the references.",
URL="http://www.rfc-editor.org/rfc/rfc921.txt"
}

@TECHREPORT{rfc922,
AUTHOR="J. C. Mogul",
TITLE="Broadcasting Internet datagrams in the presence of subnets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=922,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT="We propose simple rules for broadcasting Internet datagrams on
local networks that support broadcast, for addressing broadcasts, and
for how gateways should handle them. This RFC suggests a proposed
protocol for the ARPA-Internet community, and requests discussion and
suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc922.txt"
}

@TECHREPORT{rfc924,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Official {ARPA-Internet} protocols for connecting personal computers to the
Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=924,
PAGES=35,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT="This RFC has been replaced by RFC 991.",
URL="http://www.rfc-editor.org/rfc/rfc924.txt"
}

@TECHREPORT{rfc925,
AUTHOR="J. B. Postel",
TITLE="{Multi-LAN} address resolution",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=925,
PAGES=15,
DAYS=15,
MONTH=oct,
YEAR=1984,
ABSTRACT={The problem of treating a set of local area networks (LANs) as
one Internet network has generated some interest and concern. It is
inappropriate to give each LAN within a site a distinct ARPA-Internet
network number. It is desirable to hide the details of the
interconnections between the LANs within a site from people, gateways,
and hosts outside the site. The question arises on how to best do this,
and even how to do it at all. In RFC 917, Jeffery Mogul makes a case for
the use of {"}explicit subnets{"} in a multi-LAN environment. The explicit
subnet scheme is a call to recursively apply the mechanisms the
ARPA-Internet uses to manage networks to the problem of managing LANs
within one network. In this note I urge another approach: the use of
{"}transparent subnets{"} supported by a multi-LAN extension of the Address
Resolution Protocol. This RFC suggests a proposed protocol for the
ARPA-Internet community, and requests discussion and suggestions for
improvements.},
URL="http://www.rfc-editor.org/rfc/rfc925.txt"
}

@TECHREPORT{rfc926,
AUTHOR=" {{International Organization for Standardization}}",
TITLE="Protocol for providing the connectionless mode network services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=926,
MONTH=dec,
YEAR=1984,
ABSTRACT="This note is the draft ISO protocol roughly similar to the DoD
Internet Protocol. This document has been prepared by retyping the text
of ISO DIS 8473 of May 1984, which is currently undergoing voting within
ISO as a Draft International Standard (DIS). This document is
distributed as an RFC for information only. It does not specify a
standard for the ARPA-Internet.",
URL="http://www.rfc-editor.org/rfc/rfc926.txt"
}

@TECHREPORT{rfc927,
AUTHOR="B. Anderson",
TITLE="{TACACS} user identification Telnet option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=927,
PAGES=4,
DAYS=15,
MONTH=dec,
YEAR=1984,
ABSTRACT="The following is the description of a Telnet option designed
to facilitate double login avoidance. It is intended primarily for TAC
connections to target hosts on behalf of TAC users, but it can be used
between any two consenting hosts. For example, all hosts at one site
(e.g., BBN) can use this option to avoid double login when TELNETing to
one another. This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc927.txt"
}

@TECHREPORT{rfc928,
AUTHOR="M. A. Padlipsky",
TITLE="Introduction to proposed {DoD} standard {H-FP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=928,
PAGES=21,
DAYS=15,
MONTH=dec,
YEAR=1984,
ABSTRACT={The broad outline of the Host-Front End Protocol introduced
here and described in RFC 929 is the result of the deliberations of a
number of experienced H-FP designers, who sat as a committee of the DoD
Protocol Standards Technical Panel. It is the intent of the designers
that the protocol be subjected to multiple test implementations and
probable iteration before being agreed upon as any sort of {"}standard{"}.
Therefore, the first order of business is to declare that THIS IS A
PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to
request that any readers of these documents who are able to do test
implementations (a) do so and (b) coordinate their efforts with the
author. This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.},
URL="http://www.rfc-editor.org/rfc/rfc928.txt"
}

@TECHREPORT{rfc929,
AUTHOR="J. Lilienkamp and R. L. Mandell and M. A. Padlipsky",
TITLE="Proposed {Host-Front} End Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=929,
PAGES=56,
DAYS=15,
MONTH=dec,
YEAR=1984,
ABSTRACT="The Host-Front End Protocol introduced in RFC 928 is described
in detail in this memo. The first order of business is to declare that
THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of
business is to request that any readers of these documents who are able
to do test implementations (a) do so and (b) coordinate their efforts
with the author. This RFC suggests a proposed protocol for the
ARPA-Internet community, and requests discussion and suggestions for
improvements.",
URL="http://www.rfc-editor.org/rfc/rfc929.txt"
}

@TECHREPORT{rfc930,
AUTHOR="M. Solomon and E. Wimmers",
TITLE="Telnet terminal type option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=930,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1985,
ABSTRACT="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. Distribution of this memo is unlimited. This standard
supersedes RFC 884. The only change is to specify that the TERMINAL-TYPE
IS sub-negotiation should be sent only in response to the TERMINAL-TYPE
SEND sub-negotiation.",
URL="http://www.rfc-editor.org/rfc/rfc930.txt"
}

@TECHREPORT{rfc931,
AUTHOR="M. St. Johns",
TITLE="Authentication server",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=931,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1985,
ABSTRACT="This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
This is the second draft of this proposal (superseding RFC 912) and
incorporates a more formal description of the syntax for the request and
response dialog, as well as a change to specify the type of user
identification returned.",
URL="http://www.rfc-editor.org/rfc/rfc931.txt"
}

@TECHREPORT{rfc932,
AUTHOR="D. D. Clark",
TITLE="Subnetwork addressing scheme",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=932,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1985,
ABSTRACT="This RFC proposes an alternative addressing scheme for subnets
which, in most cases, requires no modification to host software
whatsoever. The drawbacks of this scheme are that the total number of
subnets in any one network are limited, and that modification is
required to all gateways.",
URL="http://www.rfc-editor.org/rfc/rfc932.txt"
}

@TECHREPORT{rfc933,
AUTHOR="S. Silverman",
TITLE="Output marking Telnet option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=933,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1985,
ABSTRACT="This proposed option would allow a Server-Telnet to send a
banner to a User-Telnet so that this banner would be displayed on the
workstation screen independently of the application software running in
the Server-Telnet.",
URL="http://www.rfc-editor.org/rfc/rfc933.txt"
}

@TECHREPORT{rfc934,
AUTHOR="Marshall T. Rose and Einar Stefferud",
TITLE="Proposed standard for message encapsulation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=934,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1985,
ABSTRACT={This memo concerns itself with message forwarding. Forwarding
can be thought of as encapsulating one or more messages inside another.
Although this is useful for transfer of past correspondence to new
recipients, without a decapsulation process (which this memo terms
{"}bursting{"}), the forwarded messages are of little use to the recipients
because they can not be distributed, forwarded, replied-to, or otherwise
processed as separate individual messages. In order to burst a message
it is necessary to know how the component messages were encapsulated in
the draft. At present there is no unambiguous standard for interest
group digests. This RFC proposes a proposed protocol for the
ARPA-Internet community, and requests discussion and suggestions for
improvements.},
URL="http://www.rfc-editor.org/rfc/rfc934.txt"
}

@TECHREPORT{rfc935,
AUTHOR="J. T. Robinson",
TITLE="Reliable link layer protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=935,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=1985,
ABSTRACT="This RFC discusses protocols proposed recently in RFCs 914 and
916, and suggests a proposed protocol that could meet the same needs
addressed in those memos. The stated need is reliable communication
between two programs over a full-duplex, point-to-point communication
link, and in particular the RFCs address the need for such communication
over an asynchronous link at relatively low speeds. The suggested
protocol uses the methods of existing national and international data
link layer standards. This RFC suggests a proposed protocol for the
ARPA-Internet community, and requests discussion and suggestions for
improvements.",
URL="http://www.rfc-editor.org/rfc/rfc935.txt"
}

@TECHREPORT{rfc936,
AUTHOR="Mike Karels",
TITLE="Another Internet subnet addressing scheme",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=936,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1985,
ABSTRACT="There have been several proposals for schemes to allow the use
of a single Internet network number to refer to a collection of physical
networks under common administration which are reachable from the rest
of the Internet by a common route. Such schemes allow a simplified view
of an otherwise complicated topology from hosts and gateways outside of
this collection. They allow the complexity of the number and type of
these networks, and routing to them, to be localized. Additions and
changes in configuration thus cause no detectable change, and no
interruption of service, due to slow propagation of routing and other
information outside of the local environment. These schemes also
simplify the administration of the network, as changes do not require
allocation of new network numbers for each new cable installed. This
proposal discusses an alternative scheme, one that has been in use at
the University of California, Berkeley since April 1984. This RFC
suggests a proposed protocol for the ARPA-Internet community, and
requests discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc936.txt"
}

@TECHREPORT{rfc937,
AUTHOR="M. Butler and J. B. Postel and D. Chase and J. Goldberger and J. F.
Reynolds",
TITLE="Post Office Protocol: Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=937,
PAGES=24,
DAYS=15,
MONTH=feb,
YEAR=1985,
ABSTRACT="This RFC suggests a simple method for workstations to
dynamically access mail from a mailbox server. This RFC specifies a
proposed protocol for the ARPA-Internet community, and requests
discussion and suggestions for improvement. This memo is a revision of
RFC 918.",
URL="http://www.rfc-editor.org/rfc/rfc937.txt"
}

@TECHREPORT{rfc938,
AUTHOR="T. Miller",
TITLE="Internet Reliable Transaction Protocol functional and interface
specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=938,
PAGES=16,
DAYS=15,
MONTH=feb,
YEAR=1985,
ABSTRACT="This RFC is being distributed to members of the DARPA research
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 DARPA community, they may be interesting to a
number of researchers and implementors. This RFC suggests a proposed
protocol for the ARPA-Internet community, and requests discussion and
suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc938.txt"
}

@TECHREPORT{rfc939,
AUTHOR=" {National Research Council}",
TITLE="Executive summary of the {NRC} report on transport protocols for Department
of Defense data networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=939,
PAGES=20,
DAYS=15,
MONTH=feb,
YEAR=1985,
ABSTRACT={This RFC reproduces the material from the {"}front pages{"} of the
National Research Council report resulting from a study of the DOD
Internet Protocol (IP) and Transmission Control Protocol (TCP) in
comparison with the ISO Internet Protocol (ISO-IP) and Transport
Protocol level 4 (TP-4). The point of this RFC is to make the text of
the Executive Summary widely available in a timely way. The order of
presentation has been altered, and the pagination changed.},
URL="http://www.rfc-editor.org/rfc/rfc939.txt"
}

@TECHREPORT{rfc940,
AUTHOR="Gateway Algorithms and  ",
TITLE="Toward an Internet standard scheme for subnetting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=940,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1985,
ABSTRACT="Several sites now contain a complex of local links connected
to the Internet via a gateway. The details of the internal connectivity
are of little interest to the rest of the Internet. One way of
organizing these local complexes of links is to use the same strategy as
the Internet uses to organize networks, that is, to declare each link to
be an entity (like a network) and to interconnect the links with devices
that perform routing functions (like gateways). This general scheme is
called subnetting, the individual links are called subnets, and the
connecting devices are called subgateways (or bridges, or gateways).
This RFC discusses standardizing the protocol used in subnetted
environments in the ARPA-Internet. Distribution of this memo is
unlimited. The author of this RFC is the Gateway Algorithms and Data
Structures (GADS) Task Force, chaired by David L. Mills.",
URL="http://www.rfc-editor.org/rfc/rfc940.txt"
}

@TECHREPORT{rfc941,
AUTHOR=" {{International Organization for Standardization}}",
TITLE="Addendum to the network service definition covering network layer
addressing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=941,
MONTH=apr,
YEAR=1985,
ABSTRACT="This Addendum to the Network Service Definition Standard, ISO
8348, defines the abstract syntax and semantics of the Network Address
(Network Service Access Point Address). The Network Address defined in
this Addendum is the address that appears in the primitives of the
connection-mode Network Service as the calling address, called address,
and responding address parameters, and in the primitives of the
connectionless-mode Network Service as the source address and
destination address parameters. This document is distributed as an RFC
for information only. It does not specify a standard for the
ARPA-Internet.",
URL="http://www.rfc-editor.org/rfc/rfc941.txt"
}

@TECHREPORT{rfc942,
AUTHOR=" {National Research Council}",
TITLE="Transport protocols for Department of Defense data networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=942,
PAGES=68,
DAYS=15,
MONTH=feb,
YEAR=1985,
ABSTRACT="This RFC reproduces the National Research Council report
resulting from a study of the DoD Internet Protocol (IP) and
Transmission Control Protocol (TCP) in comparison with the ISO Internet
Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).",
URL="http://www.rfc-editor.org/rfc/rfc942.txt"
}

@TECHREPORT{rfc943,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=943,
PAGES=50,
DAYS=15,
MONTH=apr,
YEAR=1985,
ABSTRACT="This RFC has been replaced by RFCs 997 and 990.",
URL="http://www.rfc-editor.org/rfc/rfc943.txt"
}

@TECHREPORT{rfc944,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Official {ARPA-Internet} protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=944,
PAGES=40,
DAYS=15,
MONTH=apr,
YEAR=1985,
ABSTRACT="This RFC has been replaced by RFC 991.",
URL="http://www.rfc-editor.org/rfc/rfc944.txt"
}

@TECHREPORT{rfc945,
AUTHOR="J. B. Postel",
TITLE="{DoD} statement on the {NRC} report",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=945,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1985,
ABSTRACT="In May 1983, the National Research Council (NRC) was asked
jointly by the DoD and NBS to study the issues and recommend a course of
action. The final report of the NRC committee was published in February
1985 (see RFC-942). The enclosed letter is from Donald C. Latham
(ASDC3I) to DCA transmitting the NRC report and requesting specific
actions relative to the recommendations of the report. This RFC
reproduces a letter from the Assistant Secretary of Defense for Command,
Control, Communications, and Intelligence (ASDC3I) to the Director of
the Defense Communications Agency (DCA). This letter is distributed for
information only.",
URL="http://www.rfc-editor.org/rfc/rfc945.txt"
}

@TECHREPORT{rfc946,
AUTHOR="R. Nedved",
TITLE="Telnet terminal location number option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=946,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1985,
ABSTRACT="Many systems provide a mechanism for finding out where a user
is logged in from usually including information about telephone
extension and office occupants names. The information is useful for
physically locating people and/or calling them on the phone. In 1982 CMU
designed and implemented a terminal location database and modified
existing network software to handle a 64-bit number called the Terminal
Location Number (or TTYLOC). It now seems appropriate to incorporate
this mechanism into the TCP-based network protocol family. The mechanism
is not viewed as a replacement for the Terminal Location Telnet Option
(SEND-LOCATION) but as a shorthand mechansim for communicating terminal
location information between hosts in a localized community. This RFC
proposes a new option for Telnet for the ARPA-Internet community, and
requests discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc946.txt"
}

@TECHREPORT{rfc947,
AUTHOR="K. Lebowitz and D. Mankins",
TITLE="Multi-network broadcasting within the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=947,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=1985,
ABSTRACT="This RFC describes the extension of a network's broadcast
domain to include more than one physical network through the use of a
broadcast packet repeater.",
URL="http://www.rfc-editor.org/rfc/rfc947.txt"
}

@TECHREPORT{rfc948,
AUTHOR="I. Winston",
TITLE="Two methods for the transmission of {IP} datagrams over {IEEE} {802.3}
networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=948,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=1985,
ABSTRACT="This memo describes two methods of encapsulating Internet
Protocol (IP) datagrams on an IEEE 802.3 network.",
URL="http://www.rfc-editor.org/rfc/rfc948.txt"
}

@TECHREPORT{rfc949,
AUTHOR="M. A. Padlipsky",
TITLE="{FTP} unique-named store command",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=949,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1985,
ABSTRACT="There are various contexts in which it would be desirable to
have an FTP command that had the effect of the present STOR but rather
than requiring the sender to specify a file name istead caused the
resultant file to have a unique name relative to the current directory.
This RFC proposes an extension to the File Transfer Protocol for the
ARPA-Internet community, and requests discussion and suggestions for
improvements.",
URL="http://www.rfc-editor.org/rfc/rfc949.txt"
}

@TECHREPORT{rfc950,
AUTHOR="J. C. Mogul and J. B. Postel",
TITLE="Internet Standard Subnetting Procedure",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=950,
PAGES=18,
DAYS=15,
MONTH=aug,
YEAR=1985,
ABSTRACT={This memo discusses the utility of {"}subnets{"} of Internet
networks, which are logically visible sub-sections of a single Internet
network. For administrative or technical reasons, many organizations
have chosen to divide one Internet network into several subnets, instead
of acquiring a set of Internet network numbers. This memo specifies
procedures for the use of subnets. These procedures are for hosts (e.g.,
workstations). The procedures used in and between subnet gateways are
not fully described. Important motivation and background information for
a subnetting standard is provided in RFC-940. This RFC specifies a
protocol for the ARPA-Internet community. If subnetting is implemented
it is strongly recommended that these procedures be followed.},
URL="http://www.rfc-editor.org/rfc/rfc950.txt"
}

@TECHREPORT{rfc951,
AUTHOR="W. J. Croft and J. Gilmore",
TITLE="Bootstrap Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=951,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=1985,
ABSTRACT="This RFC describes an IP/UDP bootstrap protocol (BOOTP) which
allows a diskless client machine to discover its own IP address, the
address of a server host, and the name of a file to be loaded into
memory and executed. The bootstrap operation can be thought of as
consisting of TWO PHASES. This RFC describes the first phase, which
could be labeled `address determination and bootfile selection'. After
this address and filename information is obtained, control passes to the
second phase of the bootstrap where a file transfer occurs. The file
transfer will typically use the TFTP protocol, since it is intended that
both phases reside in PROM on the client. However BOOTP could also work
with other protocols such as SFTP or FTP. This RFC suggests a proposed
protocol for the ARPA-Internet community, and requests discussion and
suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc951.txt"
}

@TECHREPORT{rfc952,
AUTHOR="K. Harrenstien and Mary K. Stahl and Elizabeth J. Feinler",
TITLE="{DoD} Internet host table specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=952,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=1985,
ABSTRACT="This RFC is the official specification of the format of the
Internet Host Table. This edition of the specification includes minor
revisions to RFC 810 which brings it up to date. Obsoletes RFCs 810,
608.",
URL="http://www.rfc-editor.org/rfc/rfc952.txt"
}

@TECHREPORT{rfc953,
AUTHOR="K. Harrenstien and Mary K. Stahl and Elizabeth J. Feinler",
TITLE="Hostname Server",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=953,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1985,
ABSTRACT="This RFC is the official specification of the Hostname Server
Protocol. This edition of the specification includes minor revisions to
RFC 811 which brings it up to date. Obsoletes RFC 811.",
URL="http://www.rfc-editor.org/rfc/rfc953.txt"
}

@TECHREPORT{rfc954,
AUTHOR="K. Harrenstien and Mary K. Stahl and Elizabeth J. Feinler",
TITLE="{NICNAME/WHOIS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=954,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1985,
ABSTRACT="This RFC is the official specification of the NICNAME/WHOIS
protocol. This memo describes the protocol and the service. This is an
update of RFC 812. Obsoletes RFC 812.",
URL="http://www.rfc-editor.org/rfc/rfc954.txt"
}

@TECHREPORT{rfc955,
AUTHOR="R. Braden",
TITLE="Towards a transport service for transaction processing applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=955,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=1985,
ABSTRACT={The DoD Internet Protocol Suite includes two alternative
transport service protocols, TCP and UDP, which provide virtual circuit
and datagram service, respectively. These two protocols represent points
in the space of possible transport service attributes which are quite
{"}far apart{"}. We want to examine an important class of applications,
those which perform what is often called {"}transaction processing{"}. We
will see that the communication needs for these applications fall into
the gap {"}between{"} TCP and UDP -- neither protocol is very appropriate.},
URL="http://www.rfc-editor.org/rfc/rfc955.txt"
}

@TECHREPORT{rfc956,
AUTHOR="D. L. Mills",
TITLE="Algorithms for synchronizing network clocks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=956,
PAGES=26,
DAYS=15,
MONTH=sep,
YEAR=1985,
ABSTRACT="This RFC discussed clock synchronization algorithms for the
ARPA-Internet community, and requests discussion and suggestions for
improvements. The recent interest within the Internet community in
determining accurate time from a set of mutually suspicious network
clocks has been prompted by several occasions in which errors were found
in usually reliable, accurate clock servers after thunderstorms which
disrupted their power supply. To these sources of error should be added
those due to malfunctioning hardware, defective software and operator
mistakes, as well as random errors in the mechanism used to set and
synchronize clocks. This report suggests a stochastic model and
algorithms for computing a good estimator from time-offset samples
measured between clocks connected via network links. Included in this
report are descriptions of certain experiments which give an indication
of the effectiveness of the algorithms.",
URL="http://www.rfc-editor.org/rfc/rfc956.txt"
}

@TECHREPORT{rfc957,
AUTHOR="D. L. Mills",
TITLE="Experiments in network clock synchronization",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=957,
PAGES=27,
DAYS=15,
MONTH=sep,
YEAR=1985,
ABSTRACT="This RFC discusses some experiments in clock synchronization
in the ARPA-Internet community, and requests discussion and suggestions
for improvements. One of the services frequently neglected in computer
network design is a high-quality, time-of-day clock capable of
generating accurate timestamps with small errors compared to one-way
network delays. Such a service would be useful for tracing the progress
of complex transactions, synchronizing cached data bases, monitoring
network performance and isolating problems. In this memo, one such clock
service design will be described and its performance assessed. This
design has been incorporated as an integral part of the network routing
and control protocols of the Distributed Computer Network (DCnet)
architecture.",
URL="http://www.rfc-editor.org/rfc/rfc957.txt"
}

@TECHREPORT{rfc958,
AUTHOR="D. L. Mills",
TITLE="Network Time Protocol {(NTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=958,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=1985,
ABSTRACT="This document describes the Network Time Protocol (NTP), a
protocol for synchronizing a set of network clocks using a set of
distributed clients and servers. NTP is built on the User Datagram
Protocol (UDP), which provides a connectionless transport mechanism. It
evolved from the Time Protocol and the ICMP Timestamp message and is a
suitable replacement for both. This RFC suggests a proposed protocol for
the ARPA-Internet community, and requests discussion and suggestions for
improvements.",
URL="http://www.rfc-editor.org/rfc/rfc958.txt"
}

@TECHREPORT{rfc959,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=959,
PAGES=69,
DAYS=15,
MONTH=oct,
YEAR=1985,
ABSTRACT="This memo is the official specification of the File Transfer
Protocol (FTP) for the DARPA-Internet community. The primary intent is
to clarify and correct the documentation of the FTP specification, not
to change the protocol. The following new optional commands are included
in this edition of the specification: Change to Parent Directory (CDUP),
Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD),
Make Directory (MKD), Print Directory (PWD), and System (SYST). Note
that this specification is compatible with the previous edition.",
URL="http://www.rfc-editor.org/rfc/rfc959.txt"
}

@TECHREPORT{rfc962,
AUTHOR="M. A. Padlipsky",
TITLE="{TCP-4} prime",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=962,
PAGES=2,
DAYS=15,
MONTH=nov,
YEAR=1985,
ABSTRACT="This memo is in response to Bob Braden's call for a
transaction oriented protocol (RFC-955), and continues the discussion of
a possible transaction oriented transport protocol. This memo does not
propose a standard.",
URL="http://www.rfc-editor.org/rfc/rfc962.txt"
}

@TECHREPORT{rfc963,
AUTHOR="Deepinder Sidhu",
TITLE="Some problems with the specification of the Military Standard Internet
Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=963,
PAGES=19,
DAYS=15,
MONTH=nov,
YEAR=1985,
ABSTRACT="The purpose of this RFC is to provide helpful information on
the Military Standard Internet Protocol (MIL-STD-1777) so that one can
obtain a reliable implementation of this protocol. This paper points out
several problems in this specification. This note also proposes
solutions to these problems.",
URL="http://www.rfc-editor.org/rfc/rfc963.txt"
}

@TECHREPORT{rfc964,
AUTHOR="Deepinder Sidhu",
TITLE="Some problems with the specification of the Military Standard Transmission
Control Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=964,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1985,
ABSTRACT="The purpose of this RFC is to provide helpful information on
the Military Standard Transmission Control Protocol (MIL-STD-1778) so
that one can obtain a reliable implementation of this protocol standard.
This note points out three errors with this specification. This note
also proposes solutions to these problems.",
URL="http://www.rfc-editor.org/rfc/rfc964.txt"
}

@TECHREPORT{rfc965,
AUTHOR="L. Aguilar",
TITLE="Format for a graphical communication protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=965,
PAGES=51,
DAYS=15,
MONTH=dec,
YEAR=1985,
ABSTRACT="This RFC describes the requirements for a graphical format on
which to base a graphical on-line communication protocol, and proposes
an Interactive Graphical Communication Format using the GKSM session
metafile. We hope this contribution will encourage the discussion of
multimedia data exchange and the proposal of solutions.",
URL="http://www.rfc-editor.org/rfc/rfc965.txt"
}

@TECHREPORT{rfc966,
AUTHOR="S. E. Deering and D. R. Cheriton",
TITLE="Host groups: A multicast extension to the Internet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=966,
PAGES=27,
DAYS=15,
MONTH=dec,
YEAR=1985,
ABSTRACT="This RFC defines a model of service for Internet multicasting
and proposes an extension to the Internet Protocol (IP) to support such
a multicast service. Discussion and suggestions for improvements are
requested.",
URL="http://www.rfc-editor.org/rfc/rfc966.txt"
}

@TECHREPORT{rfc967,
AUTHOR="M. A. Padlipsky",
TITLE="All victims together",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=967,
PAGES=2,
DAYS=15,
MONTH=dec,
YEAR=1985,
ABSTRACT="This RFC proposes a new set of RFCs on how the networking code
is integrated with various operating systems. It appears that this topic
has not received enough exposure in the literature. Comments and
suggestions are encouraged.",
URL="http://www.rfc-editor.org/rfc/rfc967.txt"
}

@TECHREPORT{rfc968,
AUTHOR="V. G. Cerf",
TITLE="Twas the night before start-up",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=968,
PAGES=2,
DAYS=15,
MONTH=dec,
YEAR=1985,
ABSTRACT="This memo discusses problems that arise and debugging
techniques used in bringing a new network into operation.",
URL="http://www.rfc-editor.org/rfc/rfc968.txt"
}

@TECHREPORT{rfc969,
AUTHOR="D. D. Clark and Mark L. Lambert and L. Zhang",
TITLE="{NETBLT:} A bulk data transfer protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=969,
PAGES=15,
DAYS=15,
MONTH=dec,
YEAR=1985,
ABSTRACT="This RFC has been replaced by RFC 998. This is a preliminary
discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is
intended for the rapid transfer of a large quantity of data between
computers. It provides a transfer that is reliable and flow controlled,
and is structured to provide maximum throughput over a wide variety of
networks. This description is published for discussion and comment, and
does not constitute a standard. As the proposal may change,
implementation of this document is not advised.",
URL="http://www.rfc-editor.org/rfc/rfc969.txt"
}

@TECHREPORT{rfc970,
AUTHOR="J. Nagle",
TITLE="On packet switches with infinite storage",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=970,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=1985,
ABSTRACT="The purpose of this RFC is to focus discussion on a particular
problem in the ARPA-Internet and possible methods of solution. Most
prior work on congestion in datagram systems focuses on buffer
management. In this memo, the case of a packet switch with infinite
storage is considered. 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. An unexpected
result is found that shows 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, new solutions
applicable to switches with finite storage may be found. No proposed
solutions this document are intended as standards for the ARPA-Internet
at this time.",
URL="http://www.rfc-editor.org/rfc/rfc970.txt"
}

@TECHREPORT{rfc971,
AUTHOR="A. L. DeSchon",
TITLE="Survey of data representation standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=971,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=1986,
ABSTRACT="This RFC is a comparison of several data representation
standards that are currently in use. The standards discussed are the
CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS)
standard, DARPA Multimedia Mail system, the Courier remote procedure
call protocol, and the SUN Remote Procedure Call package. No proposals
in this document are intended as standards for the ARPA-Internet at this
time. Rather, it is hoped that a general consensus will emerge as to the
appropriate approach to a data representation standard, leading
eventually to the adoption of an ARPA-Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc971.txt"
}

@TECHREPORT{rfc972,
AUTHOR="F. J. Wancho",
TITLE="Password Generator Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=972,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1986,
ABSTRACT={This RFC specifies a standard for the ARPA-Internet community.
The Password Generator Service (PWDGEN) provides a set of six randomly
generated eight-character {"}words{"} with a reasonable level of
pronounceability, using a multi-level algorithm. Hosts on the
ARPA-Internet that choose to implement a password generator service are
expected to adopt and implement this standard.},
URL="http://www.rfc-editor.org/rfc/rfc972.txt"
}

@TECHREPORT{rfc973,
AUTHOR="P. V. Mockapetris",
TITLE="Domain system changes and observations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=973,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1986,
ABSTRACT="This RFC documents updates to Domain Name System
specifications RFC-882 and RFC-883, suggests some operational
guidelines, and discusses some experiences and problem areas in the
present system.",
URL="http://www.rfc-editor.org/rfc/rfc973.txt"
}

@TECHREPORT{rfc974,
AUTHOR="C. Partridge",
TITLE="Mail routing and the domain system",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=974,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1986,
ABSTRACT="This RFC presents a description of how mail systems on the
Internet are expected to route messages based on information from the
domain system. This involves a discussion of how mailers interpret MX
RRs, which are used for message routing.",
URL="http://www.rfc-editor.org/rfc/rfc974.txt"
}

@TECHREPORT{rfc975,
AUTHOR="D. L. Mills",
TITLE="Autonomous confederations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=975,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1986,
ABSTRACT="This RFC proposes enhancements to the Exterior Gateway
Protocol (EGP) to support a simple, multiple-level routing capability
while preserving the robustness features of the current EGP model. The
enhancements generalize the concept of core system to include multiple
communities of autonomous systems, called autonomous confederations.
Discussion and suggestions for improvement are requested.",
URL="http://www.rfc-editor.org/rfc/rfc975.txt"
}

@TECHREPORT{rfc976,
AUTHOR="M. R. Horton",
TITLE="{UUCP} mail interchange format standard",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=976,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=1986,
ABSTRACT="This document defines the standard format for the transmission
of mail messages between computers in the UUCP Project. It does not
however, address the format for storage of messages on one machine, nor
the lower level transport mechanisms used to get the date from one
machine to the next. It represents a standard for conformance by hosts
in the UUCP zone.",
URL="http://www.rfc-editor.org/rfc/rfc976.txt"
}

@TECHREPORT{rfc977,
AUTHOR="B. Kantor and P. Lapsley",
TITLE="Network News Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=977,
PAGES=27,
DAYS=15,
MONTH=feb,
YEAR=1986,
ABSTRACT="NNTP specifies a protocol for the distribution, inquiry,
retrieval, and posting of news articles using a reliable stream-based
transmission of news among the ARPA-Internet community. NNTP is designed
so that news articles are stored in a central database allowing a
subscriber to select only those items he wishes to read. Indexing,
cross-referencing, and expiration of aged messages are also provided.
This RFC suggests a proposed protocol for the ARPA-Internet community,
and requests discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc977.txt"
}

@TECHREPORT{rfc978,
AUTHOR="J. F. Reynolds and R. Gillman and W. A. Brackenridge and A. Witkowski and
J. B. Postel",
TITLE="Voice File Interchange Protocol {(VFIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=978,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=1986,
ABSTRACT="The purpose of the Voice File Interchange Protocol (VFIP) is
to permit the interchange of various types of speech files between
different systems in the ARPA-Internet community. Suggestions for
improvement are encouraged.",
URL="http://www.rfc-editor.org/rfc/rfc978.txt"
}

@TECHREPORT{rfc979,
AUTHOR="Andrew G. Malis",
TITLE="{PSN} {End-to-End} functional specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=979,
PAGES=15,
DAYS=15,
MONTH=mar,
YEAR=1986,
ABSTRACT={This memo is an updated version of BBN Report 5775,
{"}End-to-End Functional Specification{"}. It describes important changes
to
the functionality of the interface between a host and the PSN (Packet
Switch Node), and should be carefully reviewed by anyone involved in
supporting a host on either the ARPANET or MILNET. The new End-to-End
Protocol (EE) is being developed in order to correct a number of
deficiencies in the old End-to-End Protocol, to improve its performance
and overall throughput, and to better equip the Packet Switch Node (also
known as the IMP) to support its current and anticipated host
population.},
URL="http://www.rfc-editor.org/rfc/rfc979.txt"
}

@TECHREPORT{rfc980,
AUTHOR="Ole J. Jacobsen and J. B. Postel",
TITLE="Protocol document order information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=980,
PAGES=12,
DAYS=15,
MONTH=mar,
YEAR=1986,
ABSTRACT="This RFC indicates how to obtain various protocol documents
used in the DARPA research community. Included is an overview of the new
1985 DDN Protocol Handbook and available sources for obtaining related
documents (such as DOD, ISO, and CCITT).",
URL="http://www.rfc-editor.org/rfc/rfc980.txt"
}

@TECHREPORT{rfc981,
AUTHOR="D. L. Mills",
TITLE="Experimental multiple-path routing algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=981,
PAGES=22,
DAYS=15,
MONTH=mar,
YEAR=1986,
ABSTRACT="This document introduces wiretap algorithms, a class of
experimental, multiple routing algorithms that compute quasi-optimum
routes for stations sharing a packet-radio broadcast channel. The
primary route (a minimum-distance path), and additional paths ordered by
distance, which serve as alternate routes should the primary route fail,
are computed. This prototype is presented as an example of a class of
routing algorithms and data-base management techniques that may find
wider application in the Internet community. Discussions and suggestions
for improvements are welcomed.",
URL="http://www.rfc-editor.org/rfc/rfc981.txt"
}

@TECHREPORT{rfc982,
AUTHOR="H. Braun",
TITLE="Guidelines for the specification of the structure of the Domain Specific
Part {(DSP)} of the {ISO} standard {NSAP} address",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=982,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=1986,
ABSTRACT={This RFC is a draft working document of the ANSI {"}Guidelines
for the Specification of the Structure of the Domain Specific Part (DSP)
of the ISO Standard NSAP Address{"}. It provides guidance to private
address administration authorities on preferred formats and semantics
for the Domain Specific Part (DSP) of an NSAP address. This RFC
specifies the way in which the DSP may be constructed so as to
facilitate efficient address assignment. This RFC is for informational
purposes only and its distribution is unlimited and does not specify a
standard of the ARPA-Internet.},
URL="http://www.rfc-editor.org/rfc/rfc982.txt"
}

@TECHREPORT{rfc983,
AUTHOR="D. E. Cass and Marshall T. Rose",
TITLE="{ISO} transport arrives on top of the {TCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=983,
PAGES=27,
DAYS=15,
MONTH=apr,
YEAR=1986,
ABSTRACT="This memo describes a proposed protocol standard for the
ARPA-Internet community. The CCITT and the ISO have defined various
session, presentation, and application recommendations which have been
adopted by the international community and numerous vendors. To the
largest extent possible, it is desirable to offer these higher level
services directly to the ARPA-Internet, without disrupting existing
facilities. This permits users to develop expertise with ISO and CCITT
applications which previously were not available in the ARPA-Internet.
The intention is that hosts within the ARPA-Internet that choose to
implement ISO TSAP services on top of the TCP be expected to adopt and
implement this standard. Suggestions for improvement are encouraged.",
URL="http://www.rfc-editor.org/rfc/rfc983.txt"
}

@TECHREPORT{rfc984,
AUTHOR="David D. Clark (M. I. T) and Mark L. Lambert (M. I. T)",
TITLE="{PCMAIL:} A distributed mail system for personal computers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=984,
PAGES=31,
DAYS=15,
MONTH=may,
YEAR=1986,
ABSTRACT={This document is a preliminary discussion of the design of a
personal-computer-based distributed mail system. Pcmail is a distributed
mail system that provides mail service to an arbitrary number of users,
each of which owns one or more personal computers (PCs). The system is
divided into two halves. The first consists of a single entity called
the {"}repository{"}. The repository is a storage center for incoming mail.
Mail for a Pcmail user can arrive externally from the Internet or
internally from other repository users. The repository also maintains a
stable copy of each user's mail state. The repository is therefore
typically a computer with a large amount of disk storage. It is
published for discussion and comment, and does not constitute a
standard. As the proposal may change, implementation of this document is
not advised.},
URL="http://www.rfc-editor.org/rfc/rfc984.txt"
}

@TECHREPORT{rfc985,
AUTHOR=" {National Science Foundation} and  ",
TITLE="Requirements for Internet gateways - draft",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=985,
PAGES=23,
DAYS=15,
MONTH=may,
YEAR=1986,
ABSTRACT="This RFC summarizes the requirements for gateways to be used
on networks supporting the DARPA Internet protocols. While it applies
specifically to the National Science Foundation research programs, the
requirements are stated in a general context and are believed applicable
throughout the Internet community. The purpose of this document is to
present guidance for vendors offering products that might be used or
adapted for use in an Internet application. It enumerates the protocols
required and gives references to RFCs and other documents describing the
current specification. Suggestions and comments on this document are
welcomed and can be sent to Dave Mills (Mills(at)D.ISI.EDU) or Dave Farber
(Farber(at)HUEY.UDEL.EDU).",
URL="http://www.rfc-editor.org/rfc/rfc985.txt"
}

@TECHREPORT{rfc986,
AUTHOR="R. Callon and H. Braun",
TITLE="Guidelines for the use of {Internet-IP} addresses in the {ISO}
{Connectionless-Mode} Network Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=986,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1986,
ABSTRACT={This RFC suggests a method to allow the existing IP
addressing, including the IP protocol field, to be used for the ISO
Connectionless Network Protocol (CLNP). This is a draft solution to one
of the problems inherent in the use of {"}ISO-grams{"} in the DoD Internet.
Related issues will be discussed in subsequent RFCs. This RFC suggests a
proposed protocol for the ARPA-Internet community, and requests
discussion and suggestions for improvements.},
URL="http://www.rfc-editor.org/rfc/rfc986.txt"
}

@TECHREPORT{rfc987,
AUTHOR="S. E. Kille",
TITLE="Mapping between {X.400} and {RFC} 822",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=987,
PAGES=69,
DAYS=15,
MONTH=jun,
YEAR=1986,
ABSTRACT="The X.400 series of protocols have been defined by CCITT to
provide an Interpersonal Messaging Service (IPMS), making use of a store
and forward Message Transfer Service. It is expected that this standard
will be implemented very widely. This document describes a set of
mappings which will enable interworking between systems operating the
X.400 protocols and systems using RFC 822 mail protocol or protocols
derived from RFC 822. This RFC suggests a proposed protocol for the
ARPA-Internet community, and requests discussion and suggestions for
improvements.",
URL="http://www.rfc-editor.org/rfc/rfc987.txt"
}

@TECHREPORT{rfc988,
AUTHOR="S. E. Deering",
TITLE="Host extensions for {IP} multicasting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=988,
PAGES=20,
DAYS=15,
MONTH=jul,
YEAR=1986,
ABSTRACT="This memo specifies the extensions required of a host
implementation of the Internet Protocol (IP) to support internetwork
multicasting. This specification supersedes that given in RFC 966, and
constitutes a proposed protocol standard for IP multicasting in the
ARPA-Internet. The reader is directed to RFC 966 for a discussion of the
motivation and rationale behind the multicasting extension specified
here.",
URL="http://www.rfc-editor.org/rfc/rfc988.txt"
}

@TECHREPORT{rfc990,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=990,
PAGES=75,
DAYS=15,
MONTH=nov,
YEAR=1986,
ABSTRACT="This Network Working Group Request for Comments documents the
currently assigned values from several series of numbers used in network
protocol implementations. This memo is an official status report on the
numbers used in protocols in the ARPA-Internet community. This memo
obsoletes RFCs 960, 943, 923, 900, 870, 820, 790, 776, 770, 762, 758,
755, 750, 739, 717, 604, 503, 433, 349, 322, 317, 204, 179, 175, 167.",
URL="http://www.rfc-editor.org/rfc/rfc990.txt"
}

@TECHREPORT{rfc991,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Official {ARPA-Internet} protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=991,
PAGES=46,
DAYS=15,
MONTH=nov,
YEAR=1986,
ABSTRACT="This RFC identifies the documents specifying the official
protocols used in the Internet. Comments indicate any revisions or
changes planned. This memo is an official status report on the numbers
used in protocols in the ARPA-Internet community. This memo obsoletes
RFCs 961, 944, 924, 901, 880, 840, 694, 661, 617, 582, 580, 552.",
URL="http://www.rfc-editor.org/rfc/rfc991.txt"
}

@TECHREPORT{rfc992,
AUTHOR="K. Birman and T. A. Joseph",
TITLE="On communication support for fault tolerant process groups",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=992,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=1986,
ABSTRACT={This memo describes a collection of multicast communication
primitives integrated with a mechanism for handling process failure and
recovery. These primitives facilitate the implementation of
fault-tolerant process groups, which can be used to provide distributed
services in an environment subject to non-malicious crash failures.
Here, we argue that the form of {"}best effort{"} reliability provided by
host groups may not address the requirements of those researchers who
are building fault tolerant software. Our basic premise is that reliable
handling of failures, recoveries, and dynamic process migration are
important aspects of programming in distributed environments, and that
communication support that provides unpredictable behavior in the
presence of such events places an unacceptable burden of complexity on
higher level application software. This complexity does not arise when
using the fault-tolerant process group alternative.},
URL="http://www.rfc-editor.org/rfc/rfc992.txt"
}

@TECHREPORT{rfc994,
AUTHOR=" {{International Organization for Standardization}}",
TITLE="Final text of {DIS} {8473,} Protocol for Providing the Connectionless-mode
Network Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=994,
MONTH=mar,
YEAR=1986,
ABSTRACT="This Protocol Standard is one of a set of International
Standards produced to facilitate the interconnection of open systems.
The set of standards covers the services and protocols required to
achieve such interconnection. This Protocol Standard is positioned with
respect to other related standards by the layers defined in the
Reference Model for Open Systems Interconnection (ISO 7498). In
particular, it is a protocol of the Network Layer. This Protocol may be
used between network-entities in end systems or in Network Layer relay
systems (or both). It provides the Connectionless-mode Network Service
as defined in Addendum 1 to the Network Service Definition Covering
Connectionless-mode Transmission (ISO 8348/AD1).",
URL="http://www.rfc-editor.org/rfc/rfc994.txt"
}

@TECHREPORT{rfc995,
AUTHOR=" {{International Organization for Standardization}}",
TITLE="End System to Intermediate System Routing Exchange Protocol for use in
conjunction with {ISO} 8473",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=995,
MONTH=apr,
YEAR=1986,
ABSTRACT="This Protocol is one of a set of International Standards
produced to facilitate the interconnection of open systems. The set of
standards covers the services and protocols required to achieve such
interconnection. This Protocol is positioned with respect to other
related standards by the layers defined in the Reference Model for Open
Systems Interconnection (ISO 7498) and by the structure defined in the
Internal Organization of the Network Layer (DIS 8648). In particular, it
is a protocol of the Network Layer. This Protocol permits End Systems
and Intermediate Systems to exchange configuration and routing
information to facilitate the operation of the routing and relaying
functions of the Network Layer.",
URL="http://www.rfc-editor.org/rfc/rfc995.txt"
}

@TECHREPORT{rfc1000,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Request For Comments reference guide",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1000,
PAGES=149,
DAYS=15,
MONTH=aug,
YEAR=1987,
ABSTRACT="This RFC Reference Guide is intended to provide a historical
account by categorizing and summarizing of the Request for Comments
numbers 1 through 999 issued between the years 1969-1987. These
documents have been crossed referenced to indicate which RFCs are
current, obsolete, or revised.",
URL="http://www.rfc-editor.org/rfc/rfc1000.txt"
}

@TECHREPORT{rfc1001,
AUTHOR="  and Internet Activities Board",
TITLE="Protocol standard for a {NetBIOS} service on a {TCP/UDP} transport:
Concepts and methods",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1001,
PAGES=68,
DAYS=15,
MONTH=mar,
YEAR=1987,
ABSTRACT={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. 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{"}.},
URL="http://www.rfc-editor.org/rfc/rfc1001.txt"
}

@TECHREPORT{rfc1002,
AUTHOR="  and Internet Activities Board",
TITLE="Protocol standard for a {NetBIOS} service on a {TCP/UDP} transport:
Detailed specifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1002,
PAGES=85,
DAYS=15,
MONTH=mar,
YEAR=1987,
ABSTRACT={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. 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 NetBIOS Service on TCP/UDP Transport:
Concepts and Methods{"}.},
URL="http://www.rfc-editor.org/rfc/rfc1002.txt"
}

@TECHREPORT{rfc1003,
AUTHOR="A. R. Katz",
TITLE="Issues in defining an equations representation standard",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1003,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1987,
ABSTRACT="This memo is intended to identify and explore issues in
defining a standard for the exchange of mathematical equations. No
attempt is made at a complete definition and more questions are asked
than are answered. Questions about the user interface are only addressed
to the extent that they affect interchange issues.",
URL="http://www.rfc-editor.org/rfc/rfc1003.txt"
}

@TECHREPORT{rfc1004,
AUTHOR="D. L. Mills",
TITLE="Distributed-protocol authentication scheme",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1004,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=1987,
ABSTRACT="The purpose of this RFC is to focus discussion on
authentication problems in the Internet and possible methods of
solution. The proposed solutions this document are not intended as
standards for the Internet at this time. Rather, it is hoped that a
general consensus will emerge as to the appropriate solution to
authentication problems, leading eventually to the adoption of
standards. This document suggests mediated access-control and
authentication procedures suitable for those cases when an association
is to be set up between users belonging to different trust environments.",
URL="http://www.rfc-editor.org/rfc/rfc1004.txt"
}

@TECHREPORT{rfc1005,
AUTHOR="A. Khanna and Andrew G. Malis",
TITLE="{ARPANET} {AHIP-E} Host Access Protocol (enhanced {AHIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1005,
PAGES=34,
DAYS=15,
MONTH=may,
YEAR=1987,
ABSTRACT="This RFC is a proposed specification for the encoding of Class
A IP addresses for use on ARPANET-style networks such as the Milnet and
Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol
(AHIP; formerly known as 1822). These enhancements increase the size of
the PSN field, allow ARPANET hosts to use logical names to address each
other, allow for the communication of type-of-service information from
the host to the PSN and enable the PSN to provide congestion feedback to
the host on a connection basis.",
URL="http://www.rfc-editor.org/rfc/rfc1005.txt"
}

@TECHREPORT{rfc1006,
AUTHOR="Marshall T. Rose and D. E. Cass",
TITLE="{ISO} transport services on top of the {TCP:} Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1006,
PAGES=18,
DAYS=15,
MONTH=may,
YEAR=1987,
ABSTRACT="This memo specifies a standard for the Internet community.
Hosts on the Internet that choose to implement ISO transport services on
top of the TCP are expected to adopt and implement this standard. TCP
port 102 is reserved for hosts which implement this standard. This memo
specifies version 3 of the protocol and supersedes RFC-983. Changes
between the protocol is described in RFC-983 and this memo are minor,
but unfortunately incompatible.",
URL="http://www.rfc-editor.org/rfc/rfc1006.txt"
}

@TECHREPORT{rfc1007,
AUTHOR="W. McCoy",
TITLE="Military supplement to the {ISO} Transport Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1007,
PAGES=23,
DAYS=15,
MONTH=jun,
YEAR=1987,
ABSTRACT="This document supplements the Transport Service and Protocol
of the International Standards Organization (ISO), IS 8072 and IS 8073,
respectively, and their formal descriptions by providing conventions,
option selections and parameter values. This RFC is being distributed to
members of the Internet community in order to solicit comments on the
Draft Military Supplement. While this document may not be directly
relevant to the research problems of the Internet, it may be of some
interest to a number of researchers and implementors.",
URL="http://www.rfc-editor.org/rfc/rfc1007.txt"
}

@TECHREPORT{rfc1008,
AUTHOR="W. McCoy",
TITLE="Implementation guide for the {ISO} Transport Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1008,
PAGES=73,
DAYS=15,
MONTH=jun,
YEAR=1987,
ABSTRACT="This RFC is being distributed to members of the Internet
community in order to solicit comments on the Implementors Guide. While
this document may not be directly relevant to the research problems of
the Internet, it may be of some interest to a number of researchers and
implementors.",
URL="http://www.rfc-editor.org/rfc/rfc1008.txt"
}

@TECHREPORT{rfc1009,
AUTHOR="R. Braden and J. B. Postel",
TITLE="Requirements for Internet gateways",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1009,
PAGES=55,
DAYS=15,
MONTH=jun,
YEAR=1987,
ABSTRACT="This RFC summarizes the requirements for gateways to be used
between networks supporting the Internet protocols. This document is a
formal statement of the requirements to be met by gateways used in the
Internet system. As such, it is an official specification for the
Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc1009.txt"
}

@TECHREPORT{rfc1010,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1010,
PAGES=44,
DAYS=15,
MONTH=may,
YEAR=1987,
ABSTRACT="This memo is an official status report on the numbers used in
protocols in the Internet community. It documents the currently assigned
values from several series of numbers including link, socket, port, and
protocol, used in network protocol implementations.",
URL="http://www.rfc-editor.org/rfc/rfc1010.txt"
}

@TECHREPORT{rfc1011,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Official Internet protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1011,
PAGES=52,
DAYS=15,
MONTH=may,
YEAR=1987,
ABSTRACT="This memo is an official status report on the protocols used
in the Internet community. It identifies the documents specifying the
official protocols used in the Internet. Comments indicate any revisions
or changes planned.",
URL="http://www.rfc-editor.org/rfc/rfc1011.txt"
}

@TECHREPORT{rfc1012,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Bibliography of Request For Comments 1 through 999",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1012,
PAGES=64,
DAYS=15,
MONTH=jun,
YEAR=1987,
ABSTRACT="This RFC is a reference guide for the Internet community which
provides a bibliographic summary of the Request for Comments numbers 1
through 999 issued between the years 1969-1987.",
URL="http://www.rfc-editor.org/rfc/rfc1012.txt"
}

@TECHREPORT{rfc1013,
AUTHOR="R. Scheifler",
TITLE="X Window System Protocol, version {11:} Alpha update April 1987",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1013,
PAGES=101,
DAYS=15,
MONTH=jun,
YEAR=1987,
ABSTRACT="This RFC is distributed to the Internet community for
information only. It does not establish an Internet standard. The X
window system has been widely reviewed and tested. The Internet
community is encouraged to experiment with it.",
URL="http://www.rfc-editor.org/rfc/rfc1013.txt"
}

@TECHREPORT{rfc1014,
AUTHOR=" {Sun Microsystems}",
TITLE="{XDR:} External Data Representation standard",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1014,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=1987,
ABSTRACT="XDR is a standard for the description and encoding of data. It
is useful for transferring data between different computer
architectures. XDR fits into ISO presentation layer, and is roughly
analogous in purpose to X.409, ISO Abstract Syntax Notation. The major
difference between these two is that XDR uses implicit typing, while
X.409 uses explicit typing. This RFC is distributed for information
only, it does not establish a Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc1014.txt"
}

@TECHREPORT{rfc1015,
AUTHOR="B. M. Leiner",
TITLE="Implementation plan for interagency research Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1015,
PAGES=24,
DAYS=15,
MONTH=jul,
YEAR=1987,
ABSTRACT={This RFC proposes an Interagency Research Internet as the
natural outgrowth of the current Internet. This is an {"}idea paper{"} and
discussion is strongly encouraged.},
URL="http://www.rfc-editor.org/rfc/rfc1015.txt"
}

@TECHREPORT{rfc1016,
AUTHOR="W. Prue and J. B. Postel",
TITLE="Something a host could do with source quench: The Source Quench Introduced
Delay {(SQuID)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1016,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=1987,
ABSTRACT={The memo is intended to explore the issue of what a host could
do with a source quench. The proposal is for each source host IP module
to introduce some delay between datagrams sent to the same destination
host. This is a {"}crazy idea paper{"} and discussion is essential.},
URL="http://www.rfc-editor.org/rfc/rfc1016.txt"
}

@TECHREPORT{rfc1017,
AUTHOR="B. M. Leiner",
TITLE="Network requirements for scientific research: Internet task force on
scientific computing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1017,
PAGES=19,
DAYS=15,
MONTH=aug,
YEAR=1987,
ABSTRACT={This RFC identifies the requirements on communication networks
for supporting scientific research. It proposes some specific areas for
near term work, as well as some long term goals. This is an {"}idea{"}
paper
and discussion is strongly encouraged.},
URL="http://www.rfc-editor.org/rfc/rfc1017.txt"
}

@TECHREPORT{rfc1018,
AUTHOR="A. A. McKenzie",
TITLE="Some comments on {SQuID}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1018,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1987,
ABSTRACT={This memo is a discussion of some of the ideas expressed in
RFC-1016 on Source Quench. This memo introduces the distinction of the
cause of congestion in a gateway between the effects of {"}Funneling{"} and
Mismatch{"}. It is offered in the same spirit as RFC-1016; to stimulate
discussion. The opinions offered are personal, not corporate, opinions.},
URL="http://www.rfc-editor.org/rfc/rfc1018.txt"
}

@TECHREPORT{rfc1019,
AUTHOR="D. Arnon",
TITLE="Report of the Workshop on Environments for Computational Mathematics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1019,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=1987,
ABSTRACT="This memo is a report on the discussion of the representation
of equations in a workshop at the ACM SIGGRAPH Conference held in
Anaheim, California on 30 July 1987.",
URL="http://www.rfc-editor.org/rfc/rfc1019.txt"
}

@TECHREPORT{rfc1021,
AUTHOR="C. Partridge and G. Trewitt",
TITLE="High-level Entity Management System {(HEMS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1021,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1987,
ABSTRACT="This memo provides a general overview of the High-level Entity
management system (HEMS). This system is experimental, and is currently
being tested in portions of the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1021.txt"
}

@TECHREPORT{rfc1022,
AUTHOR="C. Partridge and G. Trewitt",
TITLE="High-level Entity Management Protocol {(HEMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1022,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=1987,
ABSTRACT="This memo presents an application protocol for managing
network entities such as hosts, gateways, and front end machines. This
protocol is a component of the High-level Entity Management System
HEMS), described is RFC-1021. This memo also assumes a knowledge of the
ISO data encoding standard, ASN.1.",
URL="http://www.rfc-editor.org/rfc/rfc1022.txt"
}

@TECHREPORT{rfc1023,
AUTHOR="G. Trewitt and C. Partridge",
TITLE="{HEMS} monitoring and control language",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1023,
PAGES=17,
DAYS=15,
MONTH=oct,
YEAR=1987,
ABSTRACT="This RFC specifies the High-Level Entity Management System
(HEMS) Monitoring and Control Language. This language defines the
requests and replies used in HEMS. This memo assumes knowledge of the
HEMS system described in RFC-1021, and of the ISO data encoding
standard, ASN.1.",
URL="http://www.rfc-editor.org/rfc/rfc1023.txt"
}

@TECHREPORT{rfc1024,
AUTHOR="C. Partridge and G. Trewitt",
TITLE="{HEMS} variable definitions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1024,
PAGES=74,
DAYS=15,
MONTH=oct,
YEAR=1987,
ABSTRACT="This memo assigns instruction codes, defines object formats
and object semantics for use with the High-Level Monitoring and Control
Language, defined in RFC-1023. A general system has been described in
previous memos (RFC-1021, RFC-1022). This system is called the
High-Level Entity Management System (HEMS). This memo is provisional and
the definitions are subject to change. Readers should confirm with the
authors that they have the most recent version. This RFC assumes a
working knowledge of the ISO data encoding standard, ASN.1, and a
general understanding of the IP protocol suite.",
URL="http://www.rfc-editor.org/rfc/rfc1024.txt"
}

@TECHREPORT{rfc1025,
AUTHOR="J. B. Postel",
TITLE="{TCP} and {IP} bake off",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1025,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1987,
ABSTRACT="This memo describes some of the procedures, scoring and tests
used in the TCP and IP bake offs held in the early development of these
protocols. These procedures and tests may still be of use in testing
newly implemented TCP and IP modules.",
URL="http://www.rfc-editor.org/rfc/rfc1025.txt"
}

@TECHREPORT{rfc1026,
AUTHOR="S. E. Kille",
TITLE="Addendum to {RFC} {987:} (Mapping between {X.400} and {RFC-822)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1026,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1987,
ABSTRACT="This memo suggest a proposed protocol for the Internet
community, and request discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc1026.txt"
}

@TECHREPORT{rfc1027,
AUTHOR="S. Carl-Mitchell and J. S. Quarterman",
TITLE="Using {ARP} to implement transparent subnet gateways",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1027,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1987,
ABSTRACT={This RFC describes the use of the Address Resolution Protocol
(ARP) by subnet gateways to permit hosts on the connected subnets to
communicate without being aware of the existence of subnets, using the
technique of {"}Proxy ARP{"}.},
URL="http://www.rfc-editor.org/rfc/rfc1027.txt"
}

@TECHREPORT{rfc1028,
AUTHOR="J. R. Davin and J. D. Case and M. S. Fedor and M. L. Schoffstall",
TITLE="Simple Gateway Monitoring Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1028,
PAGES=35,
DAYS=15,
MONTH=nov,
YEAR=1987,
ABSTRACT="This memo defines a simple application-layer protocol by which
management information for a gateway may be inspected or altered by
remote users. This proposal is intended only as an interim response to
immediate gateway monitoring needs.",
URL="http://www.rfc-editor.org/rfc/rfc1028.txt"
}

@TECHREPORT{rfc1030,
AUTHOR="Mark L. Lambert",
TITLE="On testing the {NETBLT} Protocol over divers networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1030,
PAGES=16,
DAYS=15,
MONTH=nov,
YEAR=1987,
ABSTRACT="This memo describes the results gathered from testing NETBLT
over three networks of different bandwidths and round-trip delays. The
results are not complete, but the information gathered so far has not
been promising. The NETBLT protocol is specified in RFC-998; this
document assumes an understanding of the specification as described in
RFC-998.",
URL="http://www.rfc-editor.org/rfc/rfc1030.txt"
}

@TECHREPORT{rfc1031,
AUTHOR="W. D. Lazear",
TITLE="{MILNET} name domain transition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1031,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1987,
ABSTRACT="This RFC consolidates information necessary for the
implementation of domain style names throughout the DDN/MILNET Internet
community. The introduction of domain style names will impact all hosts
in the DDN/MILNET Internet. This RFC is designed as an aid to
implementors and administrators by providing: 1) an overview of the
transition process from host tables to domains, 2) a timetable for the
transition, and 3) references to documentation and software relating to
the domain system.",
URL="http://www.rfc-editor.org/rfc/rfc1031.txt"
}

@TECHREPORT{rfc1032,
AUTHOR="Mary K. Stahl",
TITLE="Domain administrators guide",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1032,
PAGES=14,
DAYS=15,
MONTH=nov,
YEAR=1987,
ABSTRACT="Domains are administrative entities that provide decentralized
management of host naming and addressing. The domain-naming system is
distributed and hierarchical. This memo describes procedures for
registering a domain with the Network Information Center (NIC) of
Defense Data Network (DDN), and offers guidelines on the establishment
and administration of a domain in accordance with the requirements
specified in RFC-920. It is recommended that the guidelines described in
this document be used by domain administrators in the establishment and
control of second-level domains. The role of the domain administrator
(DA) is that of coordinator, manager, and technician. If his domain is
established at the second level or lower in the tree, the domain
administrator must register by interacting with the management of the
domain directly above this.",
URL="http://www.rfc-editor.org/rfc/rfc1032.txt"
}

@TECHREPORT{rfc1033,
AUTHOR="M. Lottor",
TITLE="Domain administrators operations guide",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1033,
PAGES=22,
DAYS=15,
MONTH=nov,
YEAR=1987,
ABSTRACT="This RFC provides guidelines for domain administrators in
operating a domain server and maintaining their portion of the
hierarchical database. Familiarity with the domain system is assumed
(see RFCs 1031, 1032, 1034, and 1035).",
URL="http://www.rfc-editor.org/rfc/rfc1033.txt"
}

@TECHREPORT{rfc1034,
AUTHOR="P. V. Mockapetris",
TITLE="Domain names - concepts and facilities",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1034,
PAGES=55,
DAYS=15,
MONTH=nov,
YEAR=1987,
ABSTRACT="This RFC is the revised basic definition of The Domain Name
System. It obsoletes RFC-882. This memo describes the domain style names
and their used for host address look up and electronic mail forwarding.
It discusses the clients and servers in the domain name system and the
protocol used between them.",
URL="http://www.rfc-editor.org/rfc/rfc1034.txt"
}

@TECHREPORT{rfc1035,
AUTHOR="P. V. Mockapetris",
TITLE="Domain names - implementation and specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1035,
PAGES=55,
DAYS=15,
MONTH=nov,
YEAR=1987,
ABSTRACT="This RFC is the revised specification of the protocol and
format used in the implementation of the Domain Name System. It
obsoletes RFC-883. This memo documents the details of the domain name
client - server communication.",
URL="http://www.rfc-editor.org/rfc/rfc1035.txt"
}

@TECHREPORT{rfc1036,
AUTHOR="M. R. Horton and R. Adams",
TITLE="Standard for interchange of {USENET} messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1036,
PAGES=19,
DAYS=15,
MONTH=dec,
YEAR=1987,
ABSTRACT="This RFC defines the standard format for the interchange of
network News messages among USENET hosts. It updates and replaces
RFC-850, reflecting version B2.11 of the News program. This memo is
distributed as an RFC to make this information easily accessible to the
Internet community. It does not specify an Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc1036.txt"
}

@TECHREPORT{rfc1037,
AUTHOR="B. S. Greenberg and S. Keene",
TITLE="{NFILE} - a file access protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1037,
PAGES=86,
DAYS=15,
MONTH=dec,
YEAR=1987,
ABSTRACT="This document includes a specification of the NFILE file
access protocol and its underlying levels of protocol, the Token List
Transport Layer and Byte Stream with Mark. The goal of this
specification is to promote discussion of the ideas described here, and
to encourage designers of future file protocols to take advantage of
these ideas. A secondary goal is to make the specification available to
sites that might benefit from implementing NFILE.",
URL="http://www.rfc-editor.org/rfc/rfc1037.txt"
}

@TECHREPORT{rfc989,
AUTHOR="J. R. Linn",
TITLE="Privacy enhancement for Internet electronic mail: Part {I:} Message
encipherment and authentication procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=989,
PAGES=23,
DAYS=15,
MONTH=feb,
YEAR=1987,
ABSTRACT="This RFC suggests a proposed protocol for the Internet
community and requests discussion and suggestions for improvements. This
RFC is the outgrowth of a series of IAB Privacy Task Force meetings and
of internal working papers distributed for those meetings. This RFC
defines message encipherment and authentication procedures, as the
initial phase of an effort to provide privacy enhancement services for
electronic mail transfer in the Internet. It is intended that the
procedures defined here be compatible with a wide range of key
management approaches, including both conventional (symmetric) and
public-key (asymmetric) approaches for encryption of data encrypting
keys. Use of conventional cryptography for message text encryption
and/or authentication is anticipated. Privacy enhancement services
(confidentiality, authentication, and message integrity assurance) are
offered through the use of end-to- end cryptography between originator
and recipient User Agent processes, with no special processing
requirements imposed on the Message Transfer System at endpoints or at
intermediate relay sites. This approach allows privacy enhancement
facilities to be incorporated on a site-by-site or user-by-user basis
without impact on other Internet entities. Interoperability among
heterogeneous components and mail transport facilities is supported.",
URL="http://www.rfc-editor.org/rfc/rfc989.txt"
}

@TECHREPORT{rfc996,
AUTHOR="D. L. Mills",
TITLE="Statistics server",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=996,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1987,
ABSTRACT="This RFC specifies a standard for the ARPA Internet community.
Hosts and gateways on the DARPA Internet that choose to implement a
remote statistics monitoring facility may use this protocol to send
statistics data upon request to a monitoring center or debugging host.",
URL="http://www.rfc-editor.org/rfc/rfc996.txt"
}

@TECHREPORT{rfc997,
AUTHOR="S. Romano and Mark Stahl",
TITLE="Internet numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=997,
PAGES=42,
DAYS=15,
MONTH=mar,
YEAR=1987,
ABSTRACT="This memo is an official status report on the network numbers
used in the Internet community. As of 1-Mar-87 the Network Information
Center (NIC) at SRI International has assumed responsibility for
assignment of Network Numbers and Autonomous System Numbers. This RFC
documents the current assignments of these numbers at the time of this
transfer of responsibility.",
URL="http://www.rfc-editor.org/rfc/rfc997.txt"
}

@TECHREPORT{rfc998,
AUTHOR="D. D. Clark and Mark L. Lambert and L. Zhang",
TITLE="{NETBLT:} A bulk data transfer protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=998,
PAGES=21,
DAYS=15,
MONTH=mar,
YEAR=1987,
ABSTRACT="This document is a description of and a specification for the
NETBLT protocol. It is a revision of the specification published in
RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol
intended for the rapid transfer of a large quantity of data between
computers. It provides a transfer that is reliable and flow controlled,
and is designed to provide maximum throughput over a wide variety of
networks. Although NETBLT currently runs on top of the Internet Protocol
(IP), it should be able to operate on top of any datagram protocol
similar in function to IP. This document is published for discussion and
comment, and does not constitute a standard. The proposal may change and
certain parts of the protocol have not yet been specified;
implementation of this document is therefore not advised.",
URL="http://www.rfc-editor.org/rfc/rfc998.txt"
}

@TECHREPORT{rfc999,
AUTHOR="A. Westine and J. B. Postel",
TITLE="Requests For Comments summary notes: {900-999}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=999,
PAGES=22,
DAYS=15,
MONTH=apr,
YEAR=1987,
ABSTRACT="A summary of the Request for Comments Documents from RFC
900-999.",
URL="http://www.rfc-editor.org/rfc/rfc999.txt"
}

@TECHREPORT{rfc1029,
AUTHOR="G. Parr",
TITLE="More fault tolerant approach to address resolution for a {Multi-LAN} system
of Ethernets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1029,
PAGES=17,
DAYS=15,
MONTH=may,
YEAR=1988,
ABSTRACT="This memo discusses an extension to a Bridge Protocol to
detect and disclose changes in heighbouring host address parameters in a
Multi-Lan system of Ethernets. The problem is one which is appearing
more and more regularly as the interconnected systems grow larger on
Campuses and in Commercial Institutions. This RFC suggests a protocol
enhancement for the Internet community, and requests discussion and
suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc1029.txt"
}

@TECHREPORT{rfc1038,
AUTHOR="M. St. Johns",
TITLE="Draft revised {IP} security option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1038,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1988,
ABSTRACT={This memo is a pre-publication draft of the revised Internet
Protocol Security Option. This RFC reflects the version as approved by
the Protocol Standards Steering group, and is provided for informational
purposes only. The final version of this document will be available from
Navy publications and should not differ from this document in any major
fashion. This document will be published as a change to the MIL- STD
1777, {"}Internet Protocol{"}.},
URL="http://www.rfc-editor.org/rfc/rfc1038.txt"
}

@TECHREPORT{rfc1039,
AUTHOR="D. Latham",
TITLE="{DoD} statement on Open Systems Interconnection protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1039,
PAGES=3,
DAYS=15,
MONTH=jan,
YEAR=1988,
ABSTRACT="This RFC reproduces a memorandum issued on 2-JUL-87 from the
Assistant Secretary of Defense for Command, Control, Communications, and
Intelligence (ASDC31) to the Director of the Defense Communications
Agency (DCA). This memo is distributed for information only.",
URL="http://www.rfc-editor.org/rfc/rfc1039.txt"
}

@TECHREPORT{rfc1040,
AUTHOR="J. R. Linn",
TITLE="Privacy enhancement for Internet electronic mail: Part {I:} Message
encipherment and authentication procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1040,
PAGES=29,
DAYS=15,
MONTH=jan,
YEAR=1988,
ABSTRACT="This RFC is the Outgrowth of a series of IAB Privacy Task
Force meetings and of internal working papers distributed for those
meetings. This memo defines message encipherment and authentication
procedures, as the initial phase of an effort to provide privacy
enhancement services for electronic mail transfer in the Internet.
Detailed key management mechanisms to support these procedures will be
defined in a subsequent RFC. As a goal of this initial phase, it is
intended that the procedures defined here be compatible with a wide
range of key management approaches, including both conventional
(symmetric) and public-key (asymmetric) approaches for encryption of
data encrypting keys. Use of conventional cryptography for message text
encryption and/or integrity check computation is anticipated.",
URL="http://www.rfc-editor.org/rfc/rfc1040.txt"
}

@TECHREPORT{rfc1041,
AUTHOR="Y. Rekhter",
TITLE="Telnet 3270 regime option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1041,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1988,
ABSTRACT="This RFC specifies a proposed standard for the Internet
community. Hosts on the Internet that want to support 3270 data stream
within the Telnet protocol, are expected to adopt and implement this
standard.",
URL="http://www.rfc-editor.org/rfc/rfc1041.txt"
}

@TECHREPORT{rfc1042,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Standard for the transmission of {IP} datagrams over {IEEE} 802 networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1042,
PAGES=15,
DAYS=15,
MONTH=feb,
YEAR=1988,
ABSTRACT="This RFC specifies a standard method of encapsulating the
Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP)
requests and replies on IEEE 802 Networks to allow compatible and
interoperable implementations. This RFC specifies a protocol standard
for the Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc1042.txt"
}

@TECHREPORT{rfc1043,
AUTHOR="A. Yasuda and T. Thompson",
TITLE="Telnet Data Entry Terminal option: {DODIIS} implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1043,
PAGES=26,
DAYS=15,
MONTH=feb,
YEAR=1988,
ABSTRACT="This RFC suggests a proposed protocol on the TELNET Data Entry
Terminal (DET) Option - DODIIS Implementation for the Internet
community. It is intended that this specification be capatible with the
specification of DET Option in RFC-732. Discussion and suggests for
improvements are encouraged.",
URL="http://www.rfc-editor.org/rfc/rfc1043.txt"
}

@TECHREPORT{rfc1044,
AUTHOR="K. Hardwick and J. Lekashman",
TITLE="Internet Protocol on Network System's {HYPERchannel:} Protocol
specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1044,
PAGES=43,
DAYS=15,
MONTH=feb,
YEAR=1988,
ABSTRACT="This memo intends to provide a complete discussion of the
protocols and techniques used to embed DoD standard Internet Protocol
datagrams (and its associated higher level protocols) on Network Systems
Corporation's HYPERchannel equipment. This document is directed toward
network planners and implementors who are already familiar with the
TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on
common networks such as the DDN or the Ethernet. No great familiarity
with NSC products is assumed; an appendix is devoted to a review of NSC
technologies and protocols.",
URL="http://www.rfc-editor.org/rfc/rfc1044.txt"
}

@TECHREPORT{rfc1045,
AUTHOR="D. R. Cheriton",
TITLE="{VMTP:} Versatile Message Transaction Protocol: Protocol specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1045,
PAGES=123,
DAYS=15,
MONTH=feb,
YEAR=1988,
ABSTRACT="This memo specifies the Versatile Message Transaction Protocol
(VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically
designed to support the transaction model of communication, as
exemplified by remote procedure call (RPC). The full function of VMTP,
including support for security, real-time, asynchronous message
exchanges, streaming, multicast and idempotency, provides a rich
selection to the VMTP user level. Subsettability allows the VMTP module
for particular clients and servers to be specialized and simplified to
the services actually required. Examples of such simple clients and
servers include PROM network bootload programs, network boot servers,
data sensors and simple controllers, to mention but a few examples. This
RFC describes a protocol proposed as a standard for the Internet
community.",
URL="http://www.rfc-editor.org/rfc/rfc1045.txt"
}

@TECHREPORT{rfc1046,
AUTHOR="W. Prue and J. B. Postel",
TITLE="Queuing algorithm to provide type-of-service for {IP} links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1046,
PAGES=11,
DAYS=15,
MONTH=feb,
YEAR=1988,
ABSTRACT={This memo is intended to explore how Type-of-Service might be
implemented in the Internet. The proposal describes a method of queuing
which can provide the different classes of service. The technique also
prohibits one class of service from consuming excessive resources or
excluding other classes of service. This is an {"}idea paper{"} and
discussion is strongly encouraged.},
URL="http://www.rfc-editor.org/rfc/rfc1046.txt"
}

@TECHREPORT{rfc1047,
AUTHOR="C. Partridge",
TITLE="Duplicate messages and {SMTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1047,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1988,
ABSTRACT="An examination of a synchronization problem in the Simple Mail
Transfer Protocol (SMTP) is presented. This synchronization problem can
cause a message to be delivered multiple times. A method for avoiding
this problem is suggested. Nodding familiarity with the SMTP
specification, RFC-821, is required.",
URL="http://www.rfc-editor.org/rfc/rfc1047.txt"
}

@TECHREPORT{rfc1048,
AUTHOR="J. F. Reynolds",
TITLE="{BOOTP} vendor information extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1048,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1988,
ABSTRACT="This memo proposes an addition to the Bootstrap Protocol
(BOOTP). Comments and suggestions for improvements are sought.",
URL="http://www.rfc-editor.org/rfc/rfc1048.txt"
}

@TECHREPORT{rfc1049,
AUTHOR="M. A. Sirbu",
TITLE="Content-type header field for Internet messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1049,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1988,
ABSTRACT="This memo suggests proposed additions to the Internet Mail
Protocol, RFC-822, for the Internet community, and requests discussion
and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc1049.txt"
}

@TECHREPORT{rfc1050,
AUTHOR=" {Sun Microsystems}",
TITLE="{RPC:} Remote Procedure Call Protocol specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1050,
PAGES=24,
DAYS=15,
MONTH=apr,
YEAR=1988,
ABSTRACT="This memo specifies a message protocol used in implementing
Sun's Remote Procedure Call (RPC) package. This RFC describes a standard
that Sun Microsystems and others are using and is one they wish to
propose for the Internet's consideration. It is not an Internet standard
at this time.",
URL="http://www.rfc-editor.org/rfc/rfc1050.txt"
}

@TECHREPORT{rfc1051,
AUTHOR="P. A. Prindeville",
TITLE="Standard for the transmission of {IP} datagrams and {ARP} packets over
{ARCNET} networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1051,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1988,
ABSTRACT="This memo specifies a standard method of encapsulating
Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams
on an ARCNET. This RFC is a standard protocol for the Internet
community.",
URL="http://www.rfc-editor.org/rfc/rfc1051.txt"
}

@TECHREPORT{rfc1052,
AUTHOR="V. G. Cerf",
TITLE="{IAB} recommendations for the development of Internet network management
standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1052,
PAGES=14,
DAYS=15,
MONTH=apr,
YEAR=1988,
ABSTRACT="This RFC is intended to convey to the Internet community and
other interested parties the recommendations of the Internet Activities
Board (IAB) for the development of network management protocols for use
in the TCP/IP environment. This memo does NOT, in and of itself, define
or propose an Official Internet Protocol. It does reflect, however, the
policy of the IAB with respect to further network management development
in the short and long term.",
URL="http://www.rfc-editor.org/rfc/rfc1052.txt"
}

@TECHREPORT{rfc1053,
AUTHOR="S. Levy and T. Jacobson",
TITLE="Telnet {X.3} {PAD} option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1053,
PAGES=21,
DAYS=15,
MONTH=apr,
YEAR=1988,
ABSTRACT="This RFC proposes a new option to Telnet for the Internet
community, and requests discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc1053.txt"
}

@TECHREPORT{rfc1054,
AUTHOR="S. E. Deering",
TITLE="Host extensions for {IP} multicasting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1054,
PAGES=19,
DAYS=15,
MONTH=may,
YEAR=1988,
ABSTRACT={This memo specifies the extensions required of a host
implementation of the Internet Protocol (IP) to support multicasting. IP
multicasting is the transmission of an IP datagram to a {"}host group{"}, a
set hosts identified by a single IP destination address. A multicast
datagram is delivered to all members of its destination host group with
the same {"}best-efforts{"} reliability as regular unicast IP datagrams. It
is proposed as a standard for IP multicasting in the Internet. This
specification is a major revision of RFC-988.},
URL="http://www.rfc-editor.org/rfc/rfc1054.txt"
}

@TECHREPORT{rfc1055,
AUTHOR="J. L. Romkey",
TITLE="Nonstandard for transmission of {IP} datagrams over serial lines: {SLIP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1055,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1988,
ABSTRACT="The TCP/IP protocol family runs over a variety of network
media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines,
satellite links, and serial lines. There are standard encapsulations for
IP packets defined for many of these networks, but there is no standard
for serial lines. SLIP, Serial Line IP, is a currently a de facto
standard, commonly used for point-to-point serial connections running
TCP/IP. It is not an Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc1055.txt"
}

@TECHREPORT{rfc1056,
AUTHOR="Mark L. Lambert",
TITLE="{PCMAIL:} A distributed mail system for personal computers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1056,
PAGES=38,
DAYS=15,
MONTH=jun,
YEAR=1988,
ABSTRACT="This memo is a discussion of the Pcmail workstation based
distributed mail system. It is identical to the discussion in RFC-993,
save that a new, much simpler mail transport protocol is described. The
new transport protocol is the result of continued research into ease of
protocol implementation and use issues.",
URL="http://www.rfc-editor.org/rfc/rfc1056.txt"
}

@TECHREPORT{rfc1057,
AUTHOR=" {Sun Microsystems}",
TITLE="{RPC:} Remote Procedure Call Protocol specification: Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1057,
PAGES=25,
DAYS=15,
MONTH=jun,
YEAR=1988,
ABSTRACT="This RFC describes a standard that Sun Microsystems and others
are using, and is one we wish to propose for the Internet's
consideration. This memo is not an Internet standard at this time.",
URL="http://www.rfc-editor.org/rfc/rfc1057.txt"
}

@TECHREPORT{rfc1058,
AUTHOR="C. Hedrick",
TITLE="Routing Information Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1058,
PAGES=33,
DAYS=15,
MONTH=jun,
YEAR=1988,
ABSTRACT="This RFC describes an existing protocol for exchanging routing
information among gateways and other hosts. It is intended to be used as
a basis for developing gateway software for use in the Internet
community.",
URL="http://www.rfc-editor.org/rfc/rfc1058.txt"
}

@TECHREPORT{rfc1059,
AUTHOR="D. L. Mills",
TITLE="Network Time Protocol (version {1)} specification and implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1059,
PAGES=58,
DAYS=15,
MONTH=jul,
YEAR=1988,
ABSTRACT="This memo describes the Network Time Protocol (NTP), specifies
its formal 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 logical
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. The NTP architectures, algorithms
and protocols which have evolved over several years of implementation
and refinement are described in this document. The prototype system,
which has been in regular operation in the Internet for the last two
years, is described in an Appendix along with performance data which
shows that timekeeping accuracy throughout most portions of the Internet
can be ordinarily maintained to within a few tens of milliseconds, even
the cases of failure or disruption of clocks, time servers or nets. This
is a Draft Standard for an Elective protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1059.txt"
}

@TECHREPORT{rfc1062,
AUTHOR="S. Romano and Mary K. Stahl and M. Recker",
TITLE="Internet numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1062,
PAGES=65,
DAYS=15,
MONTH=aug,
YEAR=1988,
ABSTRACT="This memo is an official status report on the network numbers
and gateway autonomous system numbers used in the Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc1062.txt"
}

@TECHREPORT{rfc1063,
AUTHOR="J. C. Mogul and Christopher A. Kent and C. Partridge and K. McCloghrie",
TITLE="{IP} {MTU} discovery options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1063,
PAGES=11,
DAYS=15,
MONTH=jul,
YEAR=1988,
ABSTRACT="A pair of IP options that can be used to learn the minimum MTU
of a path through an internet is described, along with its possible
uses. This is a proposal for an Experimental protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1063.txt"
}

@TECHREPORT{rfc1064,
AUTHOR="M. R. Crispin",
TITLE="Interactive Mail Access Protocol: Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1064,
PAGES=26,
DAYS=15,
MONTH=jul,
YEAR=1988,
ABSTRACT={This memo suggests a method for workstations to dynamically
access mail from a mailbox server ({"}respository{"}). This RFC specifies a
standard for the SUMEX-AIM community and a proposed experimental
protocol for the Internet community. Discussion and suggestions for
improvement are requested.},
URL="http://www.rfc-editor.org/rfc/rfc1064.txt"
}

@TECHREPORT{rfc1065,
AUTHOR="K. McCloghrie and Marshall T. Rose",
TITLE="Structure and identification of management information for {TCP/IP-based}
internets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1065,
PAGES=21,
DAYS=15,
MONTH=aug,
YEAR=1988,
ABSTRACT="This RFC provides the common definitions for the structure and
identification of management information for TCP/IP-based internets. In
particular, together with its companion memos, which describe the
initial management information base along with the initial network
management protocol, these documents provide a simple, working
architecture and system for managing TCP/IP-based internets and in
particular, the Internet. This memo specifies a draft standard for the
Internet community. TCP/IP implementation in the Internet which are
network manageable are expected to adopt and implement this
specification.",
URL="http://www.rfc-editor.org/rfc/rfc1065.txt"
}

@TECHREPORT{rfc1066,
AUTHOR="K. McCloghrie and Marshall T. Rose",
TITLE="Management Information Base for network management of {TCP/IP-based}
internets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1066,
PAGES=90,
DAYS=15,
MONTH=aug,
YEAR=1988,
ABSTRACT="This RFC provides the initial version of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets in the short-term. In particular, together with
its companion memos which describe the structure of management
information along with the initial network management protocol, these
documents provide a simple, workable architecture and system for
managing TCP/IP-based internets, and in particular, the Internet. This
memo specifies a draft standard for the Internet community. TCP/IP
implementations in the Internet which are network manageable are
expected to adopt and implement this specification.",
URL="http://www.rfc-editor.org/rfc/rfc1066.txt"
}

@TECHREPORT{rfc1067,
AUTHOR="J. D. Case and M. S. Fedor and M. L. Schoffstall and J. R. Davin",
TITLE="Simple Network Management Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1067,
PAGES=33,
DAYS=15,
MONTH=aug,
YEAR=1988,
ABSTRACT="This RFC defines a simple protocol by which management
information for a network element may be inspected or altered by
logically remote users. In particular, together with its companion memos
which describe the structure of management information along with the
initial management information base, these documents provide a simple,
workable architecture and system for managing TCP/IP-based internets and
in particular, the Internet. This memo specifies a draft standard for
the Internet community. TCP/IP implementations in the Internet which are
network manageable are expected to adopt and implement this
specification.",
URL="http://www.rfc-editor.org/rfc/rfc1067.txt"
}

@TECHREPORT{rfc1068,
AUTHOR="A. L. DeSchon and R. Braden",
TITLE="Background File Transfer Program {(BFTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1068,
PAGES=27,
DAYS=15,
MONTH=aug,
YEAR=1988,
ABSTRACT="This RFC describes an Internet background file transfer
service that is built upon the third-party transfer model of FTP. No new
protocols are involved. The purpose of this memo is to stimulate
discussions on new Internet service modes.",
URL="http://www.rfc-editor.org/rfc/rfc1068.txt"
}

@TECHREPORT{rfc1071,
AUTHOR="R. Braden and David A. Borman and C. Partridge",
TITLE="Computing the Internet checksum",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1071,
PAGES=24,
DAYS=15,
MONTH=sep,
YEAR=1988,
ABSTRACT="This RFC summarizes techniques and algorithms for efficiently
computing the Internet checksum. It is not a standard, but a set of
useful implementation techniques.",
URL="http://www.rfc-editor.org/rfc/rfc1071.txt"
}

@TECHREPORT{rfc1072,
AUTHOR="V. Jacobson and R. Braden",
TITLE="{TCP} extensions for long-delay paths",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1072,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1988,
ABSTRACT="This RFC proposes a set of extensions to the TCP protocol to
provide efficient operation over a path with a high bandwidth*delay
product. These extensions are not proposed as an Internet standard at
this time. Instead, they are intended as a basis for further
experimentation and research on transport protocol performance.",
URL="http://www.rfc-editor.org/rfc/rfc1072.txt"
}

@TECHREPORT{rfc1073,
AUTHOR="D. Waitzman",
TITLE="Telnet window size option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1073,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1988,
ABSTRACT="This RFC describes a proposed Telnet option to allow a client
to convey window size to a Telnet server.",
URL="http://www.rfc-editor.org/rfc/rfc1073.txt"
}

@TECHREPORT{rfc1074,
AUTHOR="J. Rekhter",
TITLE="{NSFNET} backbone {SPF} based Interior Gateway Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1074,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1988,
ABSTRACT="This RFC is an implementation description of the standard ANSI
IS-IS and ISO ES-IS routing protocols within the NSFNET backbone
network.",
URL="http://www.rfc-editor.org/rfc/rfc1074.txt"
}

@TECHREPORT{rfc1075,
AUTHOR="D. Waitzman and C. Partridge and S. E. Deering",
TITLE="Distance Vector Multicast Routing Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1075,
PAGES=24,
DAYS=15,
MONTH=nov,
YEAR=1988,
ABSTRACT="This RFC describes a distance-vector-style routing protocol
for routing multicast datagrams through an internet. It is derived from
the Routing Information Protocol (RIP), and implements multicasting as
described in RFC-1054. This is an experimental protocol, and its
implementation is not recommended at this time.",
URL="http://www.rfc-editor.org/rfc/rfc1075.txt"
}

@TECHREPORT{rfc1076,
AUTHOR="G. Trewitt and C. Partridge",
TITLE="{HEMS} monitoring and control language",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1076,
PAGES=42,
DAYS=15,
MONTH=nov,
YEAR=1988,
ABSTRACT="This RFC specifies a query language for monitoring and control
of network entities. This RFC supercedes RFC 1023, extending the query
language and providing more discussion of the underlying issues. This
language is a component of the High-Level Entity Monitoring System
(HEMS) described in RFC 1021 and RFC 1022. Readers may wish to consult
these RFCs when reading this memo. RFC 1024 contains detailed
assignments of numbers and structures used in this system. Portions of
RFC 1024 that define query language structures are superceded by
definitions in this memo. This memo assumes a knowledge of the ISO data
encoding standard, ASN.1.",
URL="http://www.rfc-editor.org/rfc/rfc1076.txt"
}

@TECHREPORT{rfc1077,
AUTHOR="B. M. Leiner",
TITLE="Critical issues in high bandwidth networking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1077,
PAGES=46,
DAYS=15,
MONTH=nov,
YEAR=1988,
ABSTRACT="This memo presents the results of a working group on High
Bandwidth Networking. This RFC is for your information and you are
encouraged to comment on the issues presented. Use of Gigabit scale
networks include supercomputer imaging, Miltary C2 and sensor data
distribution from space. A Gigabit Network (GN) must support these
services: - Currently Provided Packet Services - Multi-Media Mail -
Multi-Media Conferencing - Computer Generated Real Time Graphics -
High-Speed Transaction Processing - Wide Area Distributed
Database/Knowledge Base Management Systems For a stream or synchronous
service a reservation system is used to set up and guarantee a constant
and steady amount of bandwidth between any two subscribers. For Gigabit
Backbones (GB), LAN speeds should be able to change irrespective of GB
speeds and vice versa. Directory services such as those found in CCITT
X.500/ISO DIS 9594 need to be provided. Usage policy is expressed by a
tariff which is upheld by accounting. Routing policies are enforced by
traffic controls. Trusted and secure communications on GNs is provided
by authentication, integrity, confidentiality, access control, and
nonrepudiation. Speeds of trunks in the next generation networks is
rising faster than the speeds of the switching elements. New designs of
switch are required to handle expensive but large bandwidths without the
switch becoming the bottleneck. Hierarchically designed networks may be
the key to managability in the next generation networks. Reliablity is
needed in future networks and is achieved through the use of
fault-tolerant switches, distributed control with self-correcting
algorithms and the protection of network control traffic. Architecture
of future networks must be divorced from the underlying transmission
technology. There is a heirarchy of progressively more effective network
management techniques: 1) Reactive Problem Management 2) Reactive
Resource Management 3) Proactive Problem Management 4) Proactive
Resource Management To prevent information overflow on human operators,
the system with have to provide increasing amounts of filtering.
thresholding and altering mechanisms. Expert systems capable of early
fault detection, diagnosis and problem resolution will become mandatory
for GNs. High level entities should have a name or logical address that
identifies them independently of location. Multicast should be provided
as a user level service as in RFC1054 for IP. The GN will alsmost
certainly be made up from point to point fibre links that will not
provide broadcast or multicast for free. Open group multicast means that
any host can multicast to the group; closed group multicast means that
only hosts which are members of the group may multicast to the group.
Closed group multicasting is adequate for applications such as
conferencing but open group multicasting is required for more
client-server applications such as file and database servers. TCP places
the checksum in the packet header, forcing the packet to be formed and
read fully before transmission can begin. ISO TP4 is worse than TCP in
that the checksum is in a variable location in the header and thus
hardware implementation is made very difficult. Special purpose
transport protocols can be designed for applications with more stringent
requirements than generic transport protocols (such as TCP and ISO TP4)
can provide. Current special purpose transport protocols include: o UDP
(user datagram protocol) o RDP (reliable datagram protocol) o LDP
(loader/debugger protocol) o NETBLT (high-speed block transfer protocol)
o NVP (network voice protocol) o PVP (packet video protocol) New generic
transport protocols such as VMTP hope to offer a wide range of service
options that help remove the need to resort to special purpose
protocols. New transport protocols should not be over optimised for
current networks and yet must not ignore the fundamental deficiencies of
current protocols. Forward Error Correction (FEC) is useful when the
bandwidth/delay ratio of the physical medium is high (ie photonic
transcontinental or transatlantic links). Operating systems must be
refined to the level of performance required of them for use with a
gigabit/sec network. Decentralised approaches to network management
should be emphasised over centralised systems. Compromising the security
of one part of a GN should not compromise the security of the entire
network. With changes future bandwidth and computing costs and
performance ratios, the trade off between user data and network control
data flows needs to be re-explored. Resource requests made by an
application to the network system must be in real terms desipte the fact
that most operating systems attempt to present a 'virtual world' to the
application level code. A protocol implementation can adapt to changes
in that [lower level] service by tuning its internal mechanisms
(time-outs, retransmission strategies, etc.)''. To minimise the effects
of failures in future networks, the system must reconfigure itself to
adapt to the new network state when a failure occurs. Small messages
(that fit into one RTD such as those generated by most applications
today) will require open-loop controls on flow and congestion. Large
messages (those taking longer than one RTD such as voice or video
streams) will require explicit resource commitment. The speed of light
and queuing delays are the most critical sources of delay faces future
gigabit/sec networks. Depending upon the actual (physical) size of the
network, the application layer programs can expect to experience delays
which differe by several orders of magnitude. The current Internet is
more or less unmanagable and is having problems with network
administrators using one logical subnet address to cover widely
geographically dispersed LANs connected with fibre or satelite links.
Routing can be based on policy (such as access rights) instead of simply
minimising some 'cost' such as delay. Connectionless protocols make
imposing a policy difficult and increase processing overhead, especially
at gateways, as no state is kept and policy decisions must be made for
every packet. Variables which can be taken into account in policy based
routing include: o Classes of users (ie large, small, commerical,
governmental, academic, etc), o) Classes of Service (what quality is
required), o) Time varying (on or off peak transmission), o) Volume
(discount and surcharges), o) Access charges (per port or bandwidth of
the ports in use), o) Distance (circuit miles, as the crow flies, number
of hops). A list of 'current' (as of November 1988) research efforts in
the USA is given.",
URL="http://www.rfc-editor.org/rfc/rfc1077.txt"
}

@TECHREPORT{rfc1078,
AUTHOR="M. Lottor",
TITLE="{TCP} port service Multiplexer {(TCPMUX)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1078,
PAGES=2,
DAYS=15,
MONTH=nov,
YEAR=1988,
ABSTRACT="This RFC proposes an Internet standard which can be used by
future TCP services instead of using 'well-known ports'.",
URL="http://www.rfc-editor.org/rfc/rfc1078.txt"
}

@TECHREPORT{rfc1079,
AUTHOR="C. Hedrick",
TITLE="Telnet terminal speed option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1079,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1988,
ABSTRACT="This RFC specifies a standard for the Internet community.
Hosts on the Internet that exchange terminal speed information within
the Telnet protocol are expected to adopt and implement this standard.",
URL="http://www.rfc-editor.org/rfc/rfc1079.txt"
}

@TECHREPORT{rfc1080,
AUTHOR="C. Hedrick",
TITLE="Telnet remote flow control option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1080,
PAGES=4,
DAYS=15,
MONTH=nov,
YEAR=1988,
ABSTRACT="This RFC specifies a standard for the Internet community.
Hosts on the Internet that do remote flow control within the Telnet
protocol are expected to adopt and implement this standard.",
URL="http://www.rfc-editor.org/rfc/rfc1080.txt"
}

@TECHREPORT{rfc1081,
AUTHOR="Marshall T. Rose",
TITLE="Post Office Protocol: Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1081,
PAGES=16,
DAYS=15,
MONTH=nov,
YEAR=1988,
ABSTRACT="This memo suggests a simple method for workstations to
dynamically access mail from a mailbox server. This RFC specifies a
proposed protocol for the Internet community, and requests discussion
and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc1081.txt"
}

@TECHREPORT{rfc1082,
AUTHOR="Marshall T. Rose",
TITLE="Post Office Protocol: Version {3:} Extended service offerings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1082,
PAGES=11,
DAYS=15,
MONTH=nov,
YEAR=1988,
ABSTRACT="This memo suggests a simple method for workstations to
dynamically access mail from a discussion group server, as an extension
to an earlier memo which dealt with dynamically accessing mail from a
mailbox server using the Post Office Protocol - Version 3 (POP3). This
RFC specifies a proposed protocol for the Internet community, and
requests discussion and suggestions for improvements. All of the
extensions described in this memo to the POP3 are OPTIONAL.",
URL="http://www.rfc-editor.org/rfc/rfc1082.txt"
}

@TECHREPORT{rfc1083,
AUTHOR="  and Internet Activities Board",
TITLE="{IAB} official protocol standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1083,
PAGES=12,
DAYS=15,
MONTH=dec,
YEAR=1988,
ABSTRACT="This memo describes the state of standardization of protocols
used in the Internet as determined by the Internet Activities Board
(IAB). An overview of the standards procedures is presented first,
followed by discussions of the standardization process and the RFC
document series, then the explanation of the terms is presented, the
lists of protocols in each stage of standardization follows, and finally
pointers to references and contacts for further information. This memo
is issued quarterly, please be sure the copy you are reading is dated
within the last three months.",
URL="http://www.rfc-editor.org/rfc/rfc1083.txt"
}

@TECHREPORT{rfc1085,
AUTHOR="Marshall T. Rose",
TITLE="{ISO} presentation services on top of {TCP/IP} based internets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1085,
PAGES=32,
DAYS=15,
MONTH=dec,
YEAR=1988,
ABSTRACT={RFC 1006 describes a mechanism for providing the ISO transport
service on top of TCP/IP. Once this method is applied, one may implement
{"}real{"} ISO applications on top of TCP/IP-based internets, by simply
implementing OSI session, presentation, and application services on top
of the transport service access point which is provided on top of the
TCP. Although straight-forward, there are some environments in which the
richness provided by the OSI application layer is desired, but it is
nonetheless impractical to implement the underlying OSI infrastructure
(i.e., the presentation, session, and transport services on top of the
TCP). This memo describes an approach for providing {"}stream-lined{"}
support of OSI application services on top of TCP/IP-based internets for
such constrained environments. This memo proposes a standard for the
Internet community.},
URL="http://www.rfc-editor.org/rfc/rfc1085.txt"
}

@TECHREPORT{rfc1086,
AUTHOR="Julian P. Onions and Marshall T. Rose",
TITLE="{ISO-TP0} bridge between {TCP} and {X.25}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1086,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=1988,
ABSTRACT="This memo proposes a standard for the Internet community.
Hosts on the Internet that choose to implement ISO TP0 transport
connectivity between TCP and X.25 based hosts are expected to experiment
with this proposal. TCP port 146 is reserved for this proposal.",
URL="http://www.rfc-editor.org/rfc/rfc1086.txt"
}

@TECHREPORT{rfc1069,
AUTHOR="R. Callon and H. Braun",
TITLE="Guidelines for the use of {Internet-IP} addresses in the {ISO}
{Connectionless-Mode} Network Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1069,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1989,
ABSTRACT={This RFC suggests an addressing scheme for use with the ISO
Connectionless Network Protocol (CLNP) in the Internet. This is a
solution to one of the problems inherent in the use of {"}ISO-grams{"} in
the Internet. This memo is a revision of RFC 986. This RFC suggests a
proposed protocol for the Internet community, and requests discussion
and suggestions for improvements.},
URL="http://www.rfc-editor.org/rfc/rfc1069.txt"
}

@TECHREPORT{rfc1070,
AUTHOR="R. A. Hagens and N. E. Hall and Marshall T. Rose",
TITLE="Use of the Internet as a subnetwork for experimentation with the {OSI}
network layer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1070,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=1989,
ABSTRACT="This RFC proposes a scenario for experimentation with the
International Organization for Standardization (ISO) Open Systems
Interconnection (OSI) network layer protocols over the Internet and
requests discussion and suggestions for improvements to this scenario.
This RFC also proposes the creation of an experimental OSI internet. To
participate in the experimental OSI internet, a system must abide by the
agreements set forth in this RFC.",
URL="http://www.rfc-editor.org/rfc/rfc1070.txt"
}

@TECHREPORT{rfc1087,
AUTHOR="  and Internet Activities Board",
TITLE="Ethics and the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1087,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1989,
ABSTRACT="This memo is a statement of policy by the Internet Activities
Board (IAB) concerning the proper use of the resources of the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1087.txt"
}

@TECHREPORT{rfc1088,
AUTHOR="L. J. McLaughlin",
TITLE="Standard for the transmission of {IP} datagrams over {NetBIOS} networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1088,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1989,
ABSTRACT="This document specifies a standard method of encapsulating the
Internet Protocol (IP) datagrams on NetBIOS networks.",
URL="http://www.rfc-editor.org/rfc/rfc1088.txt"
}

@TECHREPORT{rfc1089,
AUTHOR="M. L. Schoffstall and C. Davin and M. S. Fedor and J. D. Case",
TITLE="{SNMP} over Ethernet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1089,
PAGES=3,
DAYS=15,
MONTH=feb,
YEAR=1989,
ABSTRACT="This memo describes an experimental method by which the Simple
Network Management Protocol (SNMP) can be used over Ethernet MAC layer
framing instead of the Internet UDP/IP protocol stack. This
specification is useful for LAN based network elements that support no
higher layer protocols beyond the MAC sub-layer.",
URL="http://www.rfc-editor.org/rfc/rfc1089.txt"
}

@TECHREPORT{rfc1090,
AUTHOR="R. Ullmann",
TITLE="{SMTP} on {X.25}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1090,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1989,
ABSTRACT="This memo proposes a standard for SMTP on the virtual circuit
facility provided by the X.25 standard of the CCITT.",
URL="http://www.rfc-editor.org/rfc/rfc1090.txt"
}

@TECHREPORT{rfc1091,
AUTHOR="J. VanBokkelen",
TITLE="Telnet terminal-type option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1091,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1989,
ABSTRACT="This RFC specifies a standard for the Internet community.
Hosts on the Internet that exchange terminal type information within the
Telnet protocol are expected to adopt and implement this standard. This
standard supersedes RFC 930. A change is made to permit cycling through
a list of possible terminal types and selecting the most appropriate",
URL="http://www.rfc-editor.org/rfc/rfc1091.txt"
}

@TECHREPORT{rfc1092,
AUTHOR="J. Rekhter",
TITLE="{EGP} and policy based routing in the new {NSFNET} backbone",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1092,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=1989,
ABSTRACT="This memo discusses implementation decisions for routing
issues in the NSFNET, especially in the NSFNET Backbone. Of special
concern is the restriction of routing information to advertize the best
route as established by a policy decision.",
URL="http://www.rfc-editor.org/rfc/rfc1092.txt"
}

@TECHREPORT{rfc1093,
AUTHOR="H. Braun",
TITLE="{NSFNET} routing architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1093,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=1989,
ABSTRACT="This document describes the routing architecture for the
NSFNET centered around the new NSFNET Backbone, with specific emphasis
on the interface between the backbone and its attached networks.",
URL="http://www.rfc-editor.org/rfc/rfc1093.txt"
}

@TECHREPORT{rfc1094,
AUTHOR=" {Sun Microsystems}",
TITLE="{NFS:} Network File System Protocol specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1094,
PAGES=27,
DAYS=15,
MONTH=mar,
YEAR=1989,
ABSTRACT="This RFC describes a protocol that Sun Microsystems, Inc., and
others are using. A new version of the protocol is under development,
but others may benefit from the descriptions of the current protocol,
and discussion of some of the design issues.",
URL="http://www.rfc-editor.org/rfc/rfc1094.txt"
}

@TECHREPORT{rfc1095,
AUTHOR="U. Warrier and L. Besaw",
TITLE="Common Management Information Services and Protocol over {TCP/IP} {(CMOT)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1095,
PAGES=67,
DAYS=15,
MONTH=apr,
YEAR=1989,
ABSTRACT="This memo defines a network management architecture that uses
the International Organization for Standardization's (ISO) Common
Management Information Services/Common Management Information Protocol
(CMIS/CMIP) in a TCP/IP environment. This architecture provides a means
by which control and monitoring information can be exchanged between a
manager and a remote network element. In particular, this memo defines
the means for implementing the Draft International Standard (DIS)
version of CMIS/CMIP on top of Internet transport protocols for the
purpose of carrying management information defined in the
Internet-standard management information base. DIS CMIS/CMIP is suitable
for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming
an International Standard. Together with the relevant ISO standards and
the companion RFCs that describe the initial structure of management
information and management information base, these documents provide the
basis for a comprehensive architecture and system for managing TCP/IP-
based internets, and in particular the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1095.txt"
}

@TECHREPORT{rfc1096,
AUTHOR="G. A. Marcy",
TITLE="Telnet X display location option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1096,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1989,
ABSTRACT="This RFC specifies a standard for the Internet community.
Hosts on the Internet that transmit the X display location within the
Telnet protocol are expected to adopt and implement this standard.",
URL="http://www.rfc-editor.org/rfc/rfc1096.txt"
}

@TECHREPORT{rfc1097,
AUTHOR="B. I. Miller",
TITLE="Telnet subliminal-message option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1097,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1989,
ABSTRACT="This RFC specifies a standard for the Internet community.
Hosts on the Internet that display subliminal messages within the Telnet
protocol are expected to adopt and implement this standard.",
URL="http://www.rfc-editor.org/rfc/rfc1097.txt"
}

@TECHREPORT{rfc1098,
AUTHOR="J. D. Case and M. S. Fedor and M. L. Schoffstall and C. Davin",
TITLE="Simple Network Management Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1098,
PAGES=34,
DAYS=15,
MONTH=apr,
YEAR=1989,
ABSTRACT={This RFC is a re-release of RFC 1067, with a changed {"}Status
of this Memo{"} section. This memo defines a simple protocol by which
management information for a network element may be inspected or altered
by logically remote users. In particular, together with its companion
memos which describe the structure of management information along with
the initial management information base, these documents provide a
simple, workable architecture and system for managing TCP/IP-based
internets and in particular the Internet.},
URL="http://www.rfc-editor.org/rfc/rfc1098.txt"
}

@TECHREPORT{rfc1100,
AUTHOR="Editor J. Postel",
TITLE="{IAB} official protocol standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1100,
PAGES=14,
DAYS=15,
MONTH=apr,
YEAR=1989,
ABSTRACT="This memo describes the state of standardization of protocols
used in the Internet as determined by the Internet Activities Board
(IAB). An overview of the standards procedures is presented first,
followed by discussions of the standardization process and the RFC
document series, then the explanation of the terms is presented, the
lists of protocols in each stage of standardization follows, and finally
pointers to references and contacts for further information. This memo
is issued quarterly, please be sure the copy you are reading is dated
within the last three months. Current copies may be obtained from the
Network Information Center or from the Internet Assigned Numbers
Authority (see the contact information at the end of this memo). Do not
use this memo after 31-July-89.",
URL="http://www.rfc-editor.org/rfc/rfc1100.txt"
}

@TECHREPORT{rfc1101,
AUTHOR="P. V. Mockapetris",
TITLE="{DNS} encoding of network names and other types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1101,
PAGES=14,
DAYS=15,
MONTH=apr,
YEAR=1989,
ABSTRACT="This RFC proposes two extensions to the Domain Name System: 1)
A specific method for entering and retrieving RRs which map between
network names and numbers. 2) Ideas for a general method for describing
mappings between arbitrary identifiers and numbers. The method for
mapping between network names and addresses is a proposed standard, the
ideas for a general method are experimental.",
URL="http://www.rfc-editor.org/rfc/rfc1101.txt"
}

@TECHREPORT{rfc1102,
AUTHOR="D. D. Clark",
TITLE="Policy routing in Internet protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1102,
PAGES=22,
DAYS=15,
MONTH=may,
YEAR=1989,
ABSTRACT="The purpose of this RFC is to focus discussion on particular
problems in the Internet and possible methods of solution. No proposed
solutions in this document are intended as standards for the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1102.txt"
}

@TECHREPORT{rfc1103,
AUTHOR="D. Katz",
TITLE="Proposed standard for the transmission of {IP} datagrams over {FDDI}
Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1103,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1989,
ABSTRACT="This RFC specifies a method of encapsulating the Internet
Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests
and replies on Fiber Distributed Data Interface (FDDI) Networks.",
URL="http://www.rfc-editor.org/rfc/rfc1103.txt"
}

@TECHREPORT{rfc1104,
AUTHOR="H. Braun",
TITLE="Models of policy based routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1104,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1989,
ABSTRACT="The purpose of this RFC is to outline a variety of models for
policy based routing. The relative benefits of the different approaches
are reviewed. Discussions and comments are explicitly encouraged to move
toward the best policy based routing model that scales well within a
large internetworking environment.",
URL="http://www.rfc-editor.org/rfc/rfc1104.txt"
}

@TECHREPORT{rfc1105,
AUTHOR="K. Lougheed and Y. Rekhter",
TITLE="Border Gateway Protocol {(BGP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1105,
PAGES=17,
DAYS=15,
MONTH=jun,
YEAR=1989,
ABSTRACT="This RFC outlines a specific approach for the exchange of
network reachability information between Autonomous Systems. Updated by
RFCs 1163 and 1164.",
URL="http://www.rfc-editor.org/rfc/rfc1105.txt"
}

@TECHREPORT{rfc1106,
AUTHOR="R. Fox",
TITLE="{TCP} big window and {NAK} options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1106,
PAGES=13,
DAYS=15,
MONTH=jun,
YEAR=1989,
ABSTRACT="This memo discusses two extensions to the TCP protocol to
provide a more efficient operation over a network with a high
bandwidth*delay product. The extensions described in this document have
been implemented and shown to work using resources at NASA. This memo
describes an Experimental Protocol, these extensions are not proposed as
an Internet standard, but as a starting point for further research.",
URL="http://www.rfc-editor.org/rfc/rfc1106.txt"
}

@TECHREPORT{rfc1107,
AUTHOR="Karen Sollins",
TITLE="Plan for Internet directory services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1107,
PAGES=19,
DAYS=15,
MONTH=jul,
YEAR=1989,
ABSTRACT="This memo proposes a program to develop a directory service
for the Internet. It reports the results of a meeting held in February
1989, which was convened to review requirements and options for such a
service. This proposal is offered for comment, and does not represent a
committed research activity of the Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc1107.txt"
}

@TECHREPORT{rfc1109,
AUTHOR="V. G. Cerf",
TITLE="Report of the second Ad Hoc Network Management Review Group",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1109,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="This RFC reports an official Internet Activities Board (IAB)
policy position on the treatment of Network Management in the Internet.
This RFC presents the results and recommendations of the second Ad Hoc
Network Management Review on June 12, 1989. The results of the first
such meeting were reported in RFC 1052.",
URL="http://www.rfc-editor.org/rfc/rfc1109.txt"
}

@TECHREPORT{rfc1110,
AUTHOR="A. A. McKenzie",
TITLE="Problem with the {TCP} big window option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1110,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="This memo comments on the TCP Big Window option described in
RFC 1106.",
URL="http://www.rfc-editor.org/rfc/rfc1110.txt"
}

@TECHREPORT{rfc1111,
AUTHOR="J. B. Postel",
TITLE="Request for comments on Request for Comments: Instructions to {RFC} authors",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1111,
PAGES=6,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="This RFC specifies a standard for the Internet community.
Authors of RFCs are expected to adopt and implement this standard.",
URL="http://www.rfc-editor.org/rfc/rfc1111.txt"
}

@TECHREPORT{rfc1112,
AUTHOR="S. E. Deering",
TITLE="Host extensions for {IP} multicasting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1112,
PAGES=17,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="This memo specifies the extensions required of a host
implementation of the Internet Protocol (IP) to support multicasting.
Recommended procedure for IP multicasting in the Internet. This RFC
obsoletes RFCs 998 and 1054.",
URL="http://www.rfc-editor.org/rfc/rfc1112.txt"
}

@TECHREPORT{rfc1113,
AUTHOR="J. R. Linn",
TITLE="Privacy enhancement for Internet electronic mail: Part I - message
encipherment and authentication procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1113,
PAGES=34,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="This RFC specifies features for private electronic mail based
on encryption technology.",
URL="http://www.rfc-editor.org/rfc/rfc1113.txt"
}

@TECHREPORT{rfc1114,
AUTHOR="Stephen T. Kent and J. R. Linn",
TITLE="Privacy enhancement for Internet electronic mail: Part {II} -
certificate-based key management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1114,
PAGES=25,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="This RFC specifies the key management aspects of Privacy
Enhanced Mail.",
URL="http://www.rfc-editor.org/rfc/rfc1114.txt"
}

@TECHREPORT{rfc1115,
AUTHOR="J. R. Linn",
TITLE="Privacy enhancement for Internet electronic mail: Part {III} - algorithms,
modes, and identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1115,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="This RFC provides definitions, references, and citations for
algorithms, usage modes, and associated identifiers used in RFC-1113 and
RFC-1114 in support of privacy-enhanced electronic mail.",
URL="http://www.rfc-editor.org/rfc/rfc1115.txt"
}

@TECHREPORT{rfc1116,
AUTHOR="David A. Borman",
TITLE="Telnet Linemode option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1116,
PAGES=21,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="Hosts on the Internet that support Linemode within the Telnet
protocol are expected to adopt and implement this protocol. Obsoleted by
RFC 1184.",
URL="http://www.rfc-editor.org/rfc/rfc1116.txt"
}

@TECHREPORT{rfc1117,
AUTHOR="S. Romano and Mary K. Stahl and M. Recker",
TITLE="Internet numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1117,
PAGES=109,
DAYS=15,
MONTH=aug,
YEAR=1989,
ABSTRACT="This memo is an official status report on the network numbers
and the autonomous system numbers used in the Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc1117.txt"
}

@TECHREPORT{rfc1118,
AUTHOR="E. Krol",
TITLE="Hitchhikers guide to the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1118,
PAGES=24,
DAYS=15,
MONTH=sep,
YEAR=1989,
ABSTRACT={This RFC is being distributed to members of the Internet
community in order to make available some {"}hints{"} which will allow new
network participants to understand how the direction of the Internet is
set, how to acquire online information and how to be a good Internet
neighbor. While the information discussed may not be relevant to the
research problems of the Internet, it may be interesting to a number of
researchers and implementors. No standards are defined or specified in
this memo.},
URL="http://www.rfc-editor.org/rfc/rfc1118.txt"
}

@TECHREPORT{rfc1119,
AUTHOR="D. L. Mills",
TITLE="Network Time Protocol (version {2)} specification and implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1119,
DAYS=15,
MONTH=sep,
YEAR=1989,
ABSTRACT="This document describes the Network Time Protocol (NTP),
specifies its formal 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.",
URL="http://www.rfc-editor.org/rfc/rfc1119.txt"
}

@TECHREPORT{rfc1120,
AUTHOR="V. G. Cerf",
TITLE="Internet Activities Board",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1120,
PAGES=11,
DAYS=15,
MONTH=sep,
YEAR=1989,
ABSTRACT="This RFC provides a history and description of the Internet
Activities Board (IAB) and its subsidiary organizations. This memo is
for informational use and does not constitute a standard.",
URL="http://www.rfc-editor.org/rfc/rfc1120.txt"
}

@TECHREPORT{rfc1121,
AUTHOR="J. B. Postel and L. Kleinrock and V. G. Cerf and B. W. Boehm",
TITLE="Act one - the poems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1121,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1989,
ABSTRACT={This RFC presents a collection of poems that were presented at
{"}Act One{"}, a symposium held partially in celebration of the 20th
anniversary of the ARPANET.},
URL="http://www.rfc-editor.org/rfc/rfc1121.txt"
}

@TECHREPORT{rfc1122,
EDITOR="R. Braden",
TITLE="Requirements for Internet Hosts - Communication Layers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1122,
PAGES=116,
DAYS=15,
MONTH=oct,
YEAR=1989,
ABSTRACT="This RFC is an official specification for the Internet
community. It incorporates by reference, amends, corrects, and
supplements the primary protocol standards documents relating to hosts.",
URL="http://www.rfc-editor.org/rfc/rfc1122.txt"
}

@TECHREPORT{rfc1123,
EDITOR="R. Braden",
TITLE="Requirements for Internet Hosts - Application and Support",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1123,
PAGES=98,
DAYS=15,
MONTH=oct,
YEAR=1989,
ABSTRACT="This RFC is an official specification for the Internet
community. It incorporates by reference, amends, corrects, and
supplements the primary protocol standards documents relating to hosts.",
URL="http://www.rfc-editor.org/rfc/rfc1123.txt"
}

@TECHREPORT{rfc1124,
AUTHOR="B. M. Leiner",
TITLE="Policy issues in interconnecting networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1124,
DAYS=15,
MONTH=sep,
YEAR=1989,
ABSTRACT="To support the activities of the Federal Research Internet
Coordinating Committee (FRICC) in creating an interconnected set of
networks to serve the research community, two workshops were held to
address the technical support of policy issues that arise when
interconnecting such networks. Held under the suspices of the Internet
Activities Board at the request of the FRICC, and sponsored by NASA
through RIACS, the workshops addressed the required and feasible
technologies and architectures that could be used to satisfy the desired
policies for interconnection. The purpose of this RFC is to report the
results of these workshops.",
URL="http://www.rfc-editor.org/rfc/rfc1124.txt"
}

@TECHREPORT{rfc1125,
AUTHOR="D. Estrin",
TITLE="Policy requirements for inter Administrative Domain routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1125,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=1989,
ABSTRACT="The purpose of this memo is to focus discussion on particular
problems in the Internet and possible methods of solution. No proposed
solutions in this document are intended as standards for the Internet.
Rather, it is hoped that a general consensus will emerge as to the
appropriate solution to such problems, leading eventually to the
development and adoption of standards.",
URL="http://www.rfc-editor.org/rfc/rfc1125.txt"
}

@TECHREPORT{rfc1126,
AUTHOR="M. Little",
TITLE="Goals and functional requirements for inter-autonomous system routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1126,
PAGES=25,
DAYS=15,
MONTH=oct,
YEAR=1989,
ABSTRACT="This document describes the functional requirements for a
routing protocol to be used between autonomous systems. This document is
intended as a necessary precursor to the design of a new inter-
autonomous system routing protocol and specifies requirements for the
Internet applicable for use with the current DoD IP, the ISO IP, and
future Internet Protocols. It is intended that these requirements will
form the basis for the future development of a new inter-autonomous
systems routing architecture and protocol. This memo does not specify a
standard.",
URL="http://www.rfc-editor.org/rfc/rfc1126.txt"
}

@TECHREPORT{rfc1127,
AUTHOR="R. Braden",
TITLE="Perspective on the Host Requirements {RFCs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1127,
PAGES=20,
DAYS=15,
MONTH=oct,
YEAR=1989,
ABSTRACT="This RFC is for information only; it does not constitute a
standard, draft standard, or proposed standard, and it does not define a
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1127.txt"
}

@TECHREPORT{rfc1128,
AUTHOR="D. L. Mills",
TITLE="Measured performance of the Network Time Protocol in the Internet system",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1128,
DAYS=15,
MONTH=oct,
YEAR=1989,
ABSTRACT="This paper describes a series of experiments involving over
100,000 hosts of the Internet system and located in the U.S., Europe and
the Pacific. The experiments are designed to evaluate the availability,
accuracy and reliability of international standard time distribution
using the DARPA/NSF Internet and the Network Time Protocol (NTP), which
is specified in RFC-1119. NTP is designed specifically for use in a
large, diverse internet system operating at speeds from mundane to
lightwave. In NTP a distributed subnet of time servers operating in a
self-organizing, hierarchical, master-slave configuration exchange
precision timestamps in order to synchronize subnet clocks to each other
and national time standards via wire or radio. The experiments are
designed to locate Internet hosts and gateways that provide time by one
of three time distribution protocols and evaluate the accuracy of their
indications. For those hosts that support NTP, the experiments determine
the distribution of errors and other statistics over paths spanning
major portions of the globe. Finally, the experiments evaluate the
accuracy and reliability of precision timekeeping using NTP and typical
Internet paths involving DARPA, NSFNET and other agency networks. The
experiments demonstrate that timekeeping accuracy throughout most
portions of the Internet can be ordinarily maintained to within a few
tens of milliseconds, even in cases of failure or disruption of clocks,
time servers or networks. This memo does not specify a standard.",
URL="http://www.rfc-editor.org/rfc/rfc1128.txt"
}

@TECHREPORT{rfc1129,
AUTHOR="D. L. Mills",
TITLE="Internet Time Synchronization: The Network Time Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1129,
DAYS=15,
MONTH=oct,
YEAR=1989,
ABSTRACT="This memo describes the Network Time Protocol (NTP) designed
to distribute time information in a large, diverse internet system
operating at speeds from mundane to lightwave. It uses a returnable-
time architecture 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 time
information within a network via local routing algorithms and time
daemons. The architectures, algorithms and protocols which have evolved
to NTP over several years of implementation and refinement are described
in this paper. The synchronization subnet which has been in regular
operation in the Internet for the last several years is described along
with performance data which shows that timekeeping accuracy throughout
most portions of the Internet can be ordinarily maintained to within a
few tens of milliseconds, even in cases of failure or disruption of
clocks, time servers or networks. This memo describes the Network Time
Protocol in RFC-1119.",
URL="http://www.rfc-editor.org/rfc/rfc1129.txt"
}

@TECHREPORT{rfc1131,
AUTHOR="J. Moy",
TITLE="{OSPF} specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1131,
DAYS=15,
MONTH=oct,
YEAR=1989,
ABSTRACT="This RFC is the specification of the Open Shortest Path First
(OSPF) Internet routing protocol. OSPF is in the class of Internal
Gateway Protocols (IGPs) for distributing routing information between
gateways of a single Autonomous System. This routing protocol is based
on the link-state approach (in contrast to the distance-vector
approach). This specification was developed by the OSPF Working Group of
the Internet Engineering Task Force.",
URL="http://www.rfc-editor.org/rfc/rfc1131.txt"
}

@TECHREPORT{rfc1132,
AUTHOR="L. J. McLaughlin",
TITLE="Standard for the transmission of {802.2} packets over {IPX} networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1132,
PAGES=4,
DAYS=15,
MONTH=nov,
YEAR=1989,
ABSTRACT="This document specifies a standard method of encapsulating
802.2 packets on networks supporting Novell's Internet Packet Exchange
Protocol (IPX). It obsoletes earlier documents detailing the
transmission of Internet packets over IPX networks. It differs from
these earlier documents in that it allows for the transmission of
multiple network protocols over IPX and for the transmission of packets
through IPX bridges.",
URL="http://www.rfc-editor.org/rfc/rfc1132.txt"
}

@TECHREPORT{rfc1133,
AUTHOR="Jiunn-Hwa. Yu and H. Braun",
TITLE="Routing between the {NSFNET} and the {DDN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1133,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1989,
ABSTRACT="This document is a case study of the implementation of routing
between the NSFNET and the DDN components (the MILNET and the ARPANET).
We hope that it can be used to expand towards interconnection of other
Administrative Domains. We would welcome discussion and suggestions
about the methods employed for the interconnections. No standards are
specified in this memo.",
URL="http://www.rfc-editor.org/rfc/rfc1133.txt"
}

@TECHREPORT{rfc1134,
AUTHOR="D. Perkins",
TITLE="{Point-to-Point} Protocol: A proposal for multi-protocol transmission of
datagrams over {Point-to-Point} links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1134,
PAGES=38,
DAYS=15,
MONTH=nov,
YEAR=1989,
ABSTRACT="This proposal 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 Point-to-Point Protocol
Working Group chair by January 15, 1990. Comments will be reviewed at
the February 1990 IETF meeting, with the goal of advancing PPP to draft
standard status.",
URL="http://www.rfc-editor.org/rfc/rfc1134.txt"
}

@TECHREPORT{rfc1135,
AUTHOR="J. F. Reynolds",
TITLE="Helminthiasis of the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1135,
PAGES=33,
DAYS=15,
MONTH=dec,
YEAR=1989,
ABSTRACT="This memo takes a look back at the helminthiasis (infestation
with, or disease caused by parasitic worms) of the Internet that was
unleashed the evening of 2 November 1988. This RFC provides information
about an event that occurred in the life of the Internet. This memo does
not specify any standard. This document provides a glimpse at the
infection, its festering, and cure. The impact of the worm on the
Internet community, ethics statements, the role of the news media, crime
in the computer world, and future prevention is discussed. A
documentation review presents four publications that describe in detail
this particular parasitic computer program. Reference and bibliography
sections are also included.",
URL="http://www.rfc-editor.org/rfc/rfc1135.txt"
}

@TECHREPORT{rfc1136,
AUTHOR="S. Hares and D. Katz",
TITLE="Administrative Domains and Routing Domains: A model for routing in the
Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1136,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1989,
ABSTRACT={This RFC proposes a model for describing routing within the
Internet. The model is an adaptation of the {"}OSI Routeing Framework{"}.
This memo does not specify an Internet standard.},
URL="http://www.rfc-editor.org/rfc/rfc1136.txt"
}

@TECHREPORT{rfc1137,
AUTHOR="S. E. Kille",
TITLE="Mapping between full {RFC} 822 and {RFC} 822 with restricted encoding",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1137,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1989,
ABSTRACT="This RFC suggests an electronic mail protocol mapping for the
Internet community and UK Academic Community, and requests discussion
and suggestions for improvements. This memo does not specify an Internet
standard.",
URL="http://www.rfc-editor.org/rfc/rfc1137.txt"
}

@TECHREPORT{rfc1138,
AUTHOR="S. E. Kille",
TITLE="Mapping between {X.400(1988)} / {ISO} 10021 and {RFC} 822",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1138,
PAGES=92,
DAYS=15,
MONTH=dec,
YEAR=1989,
ABSTRACT="Ths RFC suggests an electronic mail protocol mapping for the
Internet community and UK Academic Community, and requests discussion
and suggestions for improvements. This memo does not specify an Internet
standard. This memo updates RFCs 822, 987, and 1026.",
URL="http://www.rfc-editor.org/rfc/rfc1138.txt"
}

@TECHREPORT{rfc1060,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Assigned numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1060,
PAGES=86,
DAYS=15,
MONTH=mar,
YEAR=1990,
ABSTRACT="This memo is a status report on the parameters (i.e., numbers
and keywords) used in protocols in the Internet community. Distribution
of this memo is unlimited.",
URL="http://www.rfc-editor.org/rfc/rfc1060.txt"
}

@TECHREPORT{rfc1139,
AUTHOR="R. A. Hagens",
TITLE="Echo function for {ISO} 8473",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1139,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1990,
ABSTRACT="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. 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. This memo is not intended
to compete with an ISO standard.",
URL="http://www.rfc-editor.org/rfc/rfc1139.txt"
}

@TECHREPORT{rfc1140,
AUTHOR="  and Internet Activities Board",
TITLE="{IAB} official protocol standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1140,
PAGES=27,
DAYS=15,
MONTH=may,
YEAR=1990,
ABSTRACT="This memo describes the state of standardization of protocols
used in the Internet as determined by the Internet Activities Board
(IAB). This memo is issued quarterly, please be sure the copy you are
reading is dated within the last three months. Current copies may be
obtained from the Network Information Center or from the Internet
Assigned Numbers Authority. Do not use this edition after 31-Aug-90.",
URL="http://www.rfc-editor.org/rfc/rfc1140.txt"
}

@TECHREPORT{rfc1141,
AUTHOR="T. Mallory and A. Kullberg",
TITLE="Incremental updating of the Internet checksum",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1141,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1990,
ABSTRACT="This memo correctly describes the incremental update procedure
for use with the standard Internet checksum. It is intended to replace
the description of Incremental Update in RFC 1071. This is not a
standard but rather, an implementation technique.",
URL="http://www.rfc-editor.org/rfc/rfc1141.txt"
}

@TECHREPORT{rfc1142,
EDITOR="D. Oran",
TITLE="{OSI} {IS-IS} Intra-domain Routing Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1142,
PAGES=115,
DAYS=15,
MONTH=feb,
YEAR=1990,
ABSTRACT="This RFC is a republication of ISO DP 10589 as a service to
the Internet community. This is not an Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc1142.txt"
}

@TECHREPORT{rfc1143,
AUTHOR="D. Bernstein",
TITLE="The Q Method of Implementing {TELNET} Option Negotiation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1143,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1990,
ABSTRACT="This is RFC discusses an implementation approach to option
negotiation in the Telnet protocol (RFC 854). It does not propose any
changes to the TELNET protocol. Rather, it discusses the implementation
of the protocol of one feature, only. This is not a protocol
specification. This is an experimental method of implementing a
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1143.txt"
}

@TECHREPORT{rfc1144,
AUTHOR="V. Jacobson",
TITLE="Compressing {TCP/IP} headers for low-speed serial links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1144,
PAGES=46,
DAYS=15,
MONTH=feb,
YEAR=1990,
ABSTRACT="This RFC describes a method for compressing the headers of
TCP/IP datagrams to improve performance over low speed serial links. The
motivation, implementation and performance of the method are described.
C code for a sample implementation is given for reference.",
URL="http://www.rfc-editor.org/rfc/rfc1144.txt"
}

@TECHREPORT{rfc1145,
AUTHOR="J. Zweig and C. Partridge",
TITLE="{TCP} alternate checksum options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1145,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=1990,
ABSTRACT="This memo is suggests a pair of TCP options to allow use of
alternate data checksum algorithms in the TCP header. The use of these
options is experimental, and not recommended for production use.",
URL="http://www.rfc-editor.org/rfc/rfc1145.txt"
}

@TECHREPORT{rfc1147,
AUTHOR="R. H. Stine",
TITLE="{FYI} on a Network Management Tool Catalog: Tools for Monitoring and
Debugging {TCP/IP} Internets and Interconnected Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1147,
PAGES=177,
DAYS=15,
MONTH=apr,
YEAR=1990,
ABSTRACT="The goal of this FYI memo is to provide practical information
to site administrators and network managers. This memo provides
information for the Internet community. It does not specify any
standard. It is not a statement of IAB policy or recommendations. (Also
FYI 2.) This catalog contains descriptions of several tools available to
assist network managers in debugging and maintaining TCP/IP internets
and interconnected communications resources. Entries in the catalog tell
what a tool does, how it works, and how it can be obtained.",
URL="http://www.rfc-editor.org/rfc/rfc1147.txt"
}

@TECHREPORT{rfc1148,
AUTHOR="S. E. Kille",
TITLE="Mapping between {X.400(1988)} / {ISO} 10021 and {RFC} 822",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1148,
PAGES=94,
DAYS=15,
MONTH=mar,
YEAR=1990,
ABSTRACT="This RFC suggests an electronic mail protocol mapping for the
Internet community and UK Academic Community, and requests discussion
and suggestions for improvements. This memo does not specify an Internet
standard. This edition includes material lost in editing.",
URL="http://www.rfc-editor.org/rfc/rfc1148.txt"
}

@TECHREPORT{rfc1149,
AUTHOR="D. Waitzman",
TITLE="Standard for the transmission of {IP} datagrams on avian carriers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1149,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1990,
ABSTRACT="This memo describes an experimental method for the
encapsulation of IP datagrams in avian carriers. This specification is
primarily useful in Metropolitan Area Networks. This is an experimental,
not recommended standard.",
URL="http://www.rfc-editor.org/rfc/rfc1149.txt"
}

@TECHREPORT{rfc1150,
AUTHOR="Gary Scott Malkin and J. F. Reynolds",
TITLE="{FYI} on {FYI:} Introduction to the {FYI} Notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1150,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1990,
ABSTRACT="This memo is the first in a new sub-series of RFCs called FYIs
(For Your Information). This memo provides information for the Internet
community. It does not specify any standard. (Also FYI 1.)",
URL="http://www.rfc-editor.org/rfc/rfc1150.txt"
}

@TECHREPORT{rfc1151,
AUTHOR="C. Partridge and Robert Hinden",
TITLE="Version 2 of the Reliable Data Protocol {(RDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1151,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1990,
ABSTRACT="This RFC suggests several updates to the specification of the
Reliable Data Protocol (RDP) in RFC-908 based on experience with the
protocol. This revised version of the protocol is experimental.",
URL="http://www.rfc-editor.org/rfc/rfc1151.txt"
}

@TECHREPORT{rfc1152,
AUTHOR="C. Partridge",
TITLE="Workshop report: Internet research steering group workshop on
very-high-speed networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1152,
PAGES=23,
DAYS=15,
MONTH=apr,
YEAR=1990,
ABSTRACT="This memo is a report on a workshop sponsored by the Internet
Research Steering Group. This memo is for information only. This RFC
does not specify an Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc1152.txt"
}

@TECHREPORT{rfc1153,
AUTHOR="F. J. Wancho",
TITLE="Digest message format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1153,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1990,
ABSTRACT="This memo describes the de facto standard Digest Message
Format. This is an elective experimental protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1153.txt"
}

@TECHREPORT{rfc1154,
AUTHOR="D. Robinson and R. Ullmann",
TITLE="Encoding header field for internet messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1154,
PAGES=7,
DAYS=15,
MONTH=apr,
YEAR=1990,
ABSTRACT="This RFC proposes an elective experimental Encoding header
field to permit the mailing of multi-part, multi-structured messages.
The use of Encoding updates RFC 1049 (Content-Type), and is a suggested
update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).",
URL="http://www.rfc-editor.org/rfc/rfc1154.txt"
}

@TECHREPORT{rfc1155,
AUTHOR="Marshall T. Rose and K. McCloghrie",
TITLE="Structure and identification of management information for {TCP/IP-based}
internets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1155,
PAGES=22,
DAYS=15,
MONTH=may,
YEAR=1990,
ABSTRACT={This RFC is a re-release of RFC 1065, with a changed {"}Status
of this Memo{"}, plus a few minor typographical corrections. The technical
content of the document is unchanged from RFC 1065.},
URL="http://www.rfc-editor.org/rfc/rfc1155.txt"
}

@TECHREPORT{rfc1156,
AUTHOR="K. McCloghrie and Marshall T. Rose",
TITLE="Management Information Base for network management of {TCP/IP-based}
internets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1156,
PAGES=91,
DAYS=15,
MONTH=may,
YEAR=1990,
ABSTRACT={This RFC is a re-release of RFC 1066, with a changed {"}Status
of this Memo{"}, {"}IAB Policy Statement{"}, and {"}Introduction{"}
sections plus
a few minor typographical corrections. The technical content of the
document is unchanged from RFC 1066.},
URL="http://www.rfc-editor.org/rfc/rfc1156.txt"
}

@TECHREPORT{rfc1157,
AUTHOR="J. D. Case and M. S. Fedor and M. L. Schoffstall and C. Davin",
TITLE="Simple Network Management Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1157,
PAGES=36,
DAYS=15,
MONTH=may,
YEAR=1990,
ABSTRACT={This RFC is a re-release of RFC 1098, with a changed {"}Status
of this Memo{"} section plus a few minor typographical corrections. This
memo defines a simple protocol by which management information for a
network element may be inspected or altered by logically remote users.},
URL="http://www.rfc-editor.org/rfc/rfc1157.txt"
}

@TECHREPORT{rfc1158,
AUTHOR="Marshall T. Rose",
TITLE="Management Information Base for network management of {TCP/IP-based}
internets: {MIB-II}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1158,
PAGES=133,
DAYS=15,
MONTH=may,
YEAR=1990,
ABSTRACT="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. This document on MIB-II incorporates all of the
technical content of RFC 1156 on MIB-I and extends it, without loss of
compatibilty.",
URL="http://www.rfc-editor.org/rfc/rfc1158.txt"
}

@TECHREPORT{rfc1159,
AUTHOR="R. T. Nelson",
TITLE="Message Send Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1159,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1990,
ABSTRACT="This RFC suggests an Experimental Protocol for the Internet
community. Hosts on the Internet that choose to implement a Message Send
Protocol may experiment with this protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1159.txt"
}

@TECHREPORT{rfc1160,
AUTHOR="V. G. Cerf",
TITLE="Internet Activities Board",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1160,
PAGES=11,
DAYS=15,
MONTH=may,
YEAR=1990,
ABSTRACT="This RFC provides a history and description of the Internet
Activities Board (IAB) and its subsidiary organizations. This memo is
for informational use and does not constitute a standard. This is a
revision of RFC 1120.",
URL="http://www.rfc-editor.org/rfc/rfc1160.txt"
}

@TECHREPORT{rfc1161,
AUTHOR="Marshall T. Rose",
TITLE="{SNMP} over {OSI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1161,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=1990,
ABSTRACT="This memo defines an experimental means for running the Simple
Network Management Protocol (SNMP) over OSI transports. This memo does
not specify a standard for the Internet community,",
URL="http://www.rfc-editor.org/rfc/rfc1161.txt"
}

@TECHREPORT{rfc1162,
AUTHOR="G. Satz",
TITLE="Connectionless Network Protocol {(ISO} {8473)} and End System to
Intermediate System {(ISO} {9542)} Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1162,
PAGES=70,
DAYS=15,
MONTH=jun,
YEAR=1990,
ABSTRACT="This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. This memo does not specify a standard for the
Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc1162.txt"
}

@TECHREPORT{rfc1163,
AUTHOR="K. Lougheed and Y. Rekhter",
TITLE="Border Gateway Protocol {(BGP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1163,
PAGES=29,
DAYS=15,
MONTH=jun,
YEAR=1990,
ABSTRACT={This RFC, together with its companion RFC-1164, {"}Application
of the Border Gateway Protocol in the Internet{"}, specify an
inter-autonomous system routing protocol for the Internet.},
URL="http://www.rfc-editor.org/rfc/rfc1163.txt"
}

@TECHREPORT{rfc1164,
AUTHOR="J. C. Honig and D. Katz and M. Mathis and Y. Rekhter and Jiunn-Hwa. Yu",
TITLE="Application of the Border Gateway Protocol in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1164,
PAGES=23,
DAYS=15,
MONTH=jun,
YEAR=1990,
ABSTRACT={This RFC, together with its companion RFC-1163, {"}A Border
Gateway Protocol (BGP){"}, specify an inter-autonomous system routing
protocol for the Internet.},
URL="http://www.rfc-editor.org/rfc/rfc1164.txt"
}

@TECHREPORT{rfc1165,
AUTHOR="Jon Crowcroft and Julian P. Onions",
TITLE="Network Time Protocol {(NTP)} over the {OSI} Remote Operations Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1165,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1990,
ABSTRACT="This memo suggests an Experimental Protocol for the OSI and
Internet communities. Hosts in either community, and in particular those
on both are encouraged to experiment with this mechanism.",
URL="http://www.rfc-editor.org/rfc/rfc1165.txt"
}

@TECHREPORT{rfc1166,
AUTHOR="S. Kirkpatrick and Mary K. Stahl and M. Recker",
TITLE="Internet numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1166,
PAGES=182,
DAYS=15,
MONTH=jul,
YEAR=1990,
ABSTRACT="This memo is a status report on the network numbers and
autonomous system numbers used in the Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc1166.txt"
}

@TECHREPORT{rfc1167,
AUTHOR="V. G. Cerf",
TITLE="Thoughts on the National Research and Education Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1167,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1990,
ABSTRACT="The memo provides a brief outline of a National Research and
Education Network (NREN). This memo provides information for the
Internet community. It does not specify any standard. It is not a
statement of IAB policy or recommendations.",
URL="http://www.rfc-editor.org/rfc/rfc1167.txt"
}

@TECHREPORT{rfc1168,
AUTHOR="A. Westine and A. L. DeSchon and J. B. Postel and Christopher Ward",
TITLE="Intermail and Commercial Mail Relay services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1168,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=1990,
ABSTRACT="This RFC discusses the history and evolution of the Intermail
and Commercial mail systems. The problems encountered in operating a
store-and-forward mail relay between commercial systems such as
Telemail, MCI Mail and Dialcom are also discussed. This RFC provides
information for the Internet community, and does not specify any
standard.",
URL="http://www.rfc-editor.org/rfc/rfc1168.txt"
}

@TECHREPORT{rfc1169,
AUTHOR="V. G. Cerf and K. Mills",
TITLE="Explaining the role of {GOSIP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1169,
PAGES=15,
DAYS=15,
MONTH=aug,
YEAR=1990,
ABSTRACT="This informational RFC represents the official view of the
Internet Activities Board (IAB), after coordination with the Federal
Networking Council (FNC). This RFC does not specify a standard.",
URL="http://www.rfc-editor.org/rfc/rfc1169.txt"
}

@TECHREPORT{rfc1171,
AUTHOR="D. Perkins",
TITLE="{Point-to-Point} Protocol for the transmission of multi-protocol datagrams
over {Point-to-Point} links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1171,
PAGES=48,
DAYS=15,
MONTH=jul,
YEAR=1990,
ABSTRACT="This memo specifies the Point-to-Point Protocol (PPP) as a
Draft Standard Protocol for the Internet community. When it becomes a
full Standard, this protocol will be recommended for all TCP/IP
implementations that communicate over serial links.",
URL="http://www.rfc-editor.org/rfc/rfc1171.txt"
}

@TECHREPORT{rfc1172,
AUTHOR="D. Perkins and R. Hobby",
TITLE="{Point-to-Point} Protocol {(PPP)} initial configuration options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1172,
PAGES=38,
DAYS=15,
MONTH=jul,
YEAR=1990,
ABSTRACT="This memo specifies the Point-to-Point Protocol (PPP) Initial
Configuration Options as a Proposed Standard Protocol for the Internet
community. When it becomes a full Standard, this protocol will be
recommended for all TCP/IP implementations that communicate over serial
links.",
URL="http://www.rfc-editor.org/rfc/rfc1172.txt"
}

@TECHREPORT{rfc1173,
AUTHOR="J. VanBokkelen",
TITLE={Responsibilities of host and network managers: A summary of the {"}oral
tradition{"} of the Internet},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1173,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1990,
ABSTRACT={This informational RFC describes the conventions to be
followed by those in charge of networks and hosts in the Internet. It is
a summary of the {"}oral tradition{"} of the Internet on this subject. (RFC
Editor's note: This memo is a contribution by the author of his view of
these conventions. It is expected that this RFC will provide a basis for
the development of official policies in the future.) These conventions
may be supplemented or amended by the policies of specific local and
regional components of the Internet. This RFC does not specify a
standard, or a policy of the IAB.},
URL="http://www.rfc-editor.org/rfc/rfc1173.txt"
}

@TECHREPORT{rfc1174,
AUTHOR="V. G. Cerf",
TITLE={{IAB} recommended policy on distributing internet identifier assignment and
{IAB} recommended policy change to internet {"}connected{"} status},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1174,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1990,
ABSTRACT="This informational RFC represents the official view of the
Internet Activities Board (IAB), and describes the recommended policies
and procedures on distributing Internet identifier assignments and
dropping the connected status requirement. This RFC does not specify a
standard.",
URL="http://www.rfc-editor.org/rfc/rfc1174.txt"
}

@TECHREPORT{rfc1175,
AUTHOR="K. L. Bowers and T. LaQuey and J. F. Reynolds and K. Roubicek and Mary K.
Stahl and A. Yuan",
TITLE="{FYI} on where to start: A bibliography of internetworking information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1175,
PAGES=42,
DAYS=15,
MONTH=aug,
YEAR=1990,
ABSTRACT="This FYI RFC is a bibliography of information about TCP/IP
internetworking, prepared by the User Services Working Group (USWG) of
the Internet Engineering Task Force (IETF). This memo provides
information for the Internet community. It does not specify any
standard. (Also FYI 3.)",
URL="http://www.rfc-editor.org/rfc/rfc1175.txt"
}

@TECHREPORT{rfc1176,
AUTHOR="M. R. Crispin",
TITLE="Interactive Mail Access Protocol: Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1176,
PAGES=30,
DAYS=15,
MONTH=aug,
YEAR=1990,
ABSTRACT={This RFC suggests a method for personal computers and
workstations to dynamically access mail from a mailbox server
({"}repository{"}). It obosoletes RFC 1064. This RFC specifies an
Experimental Protocol for the Internet community. Discussion and
suggestions for improvement are requested. Please refer to the current
edition of the {"}IAB Official Protocol Standards{"} for the
standardization
state and status of this protocol.},
URL="http://www.rfc-editor.org/rfc/rfc1176.txt"
}

@TECHREPORT{rfc1177,
AUTHOR="Gary Scott Malkin and A. N. Marine and J. F. Reynolds",
TITLE={{FYI} on Questions and Answers: Answers to commonly asked {"}new internet
user{"} questions},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1177,
PAGES=24,
DAYS=15,
MONTH=aug,
YEAR=1990,
ABSTRACT={This FYI RFC is one of three FYI's called, {"}Questions and
Answers{"} (Q/A), produced by the User Services Working Group (USWG) of
the Internet Engineering Task Force (IETF). The goal is to document the
most commonly asked questions and answers in the Internet. This memo
provides information for the Internet community. It does not specify any
standard. (Also FYI 4.)},
URL="http://www.rfc-editor.org/rfc/rfc1177.txt"
}

@TECHREPORT{rfc1178,
AUTHOR="D. Libes",
TITLE="Choosing a name for your computer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1178,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1990,
ABSTRACT="This FYI RFC is a republication of a Communications of the ACM
article on guidelines on what to do and what not to do when naming your
computer. This memo provides information for the Internet community. It
does not specify any standard. (Also FYI 5.)",
URL="http://www.rfc-editor.org/rfc/rfc1178.txt"
}

@TECHREPORT{rfc1179,
AUTHOR="L. J. McLaughlin",
TITLE="Line printer daemon protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1179,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=1990,
ABSTRACT={This RFC describes an existing print server protocol widely
used on the Internet for communicating between line printer daemons
(both clients and servers). This memo is for informational purposes
only, and does not specify an Internet standard. Please refer to the
current edition of the {"}IAB Official Protocol Standards{"} for the
standardization state and status of this protocol.},
URL="http://www.rfc-editor.org/rfc/rfc1179.txt"
}

@TECHREPORT{rfc1181,
AUTHOR="R. Blokzijl",
TITLE="{RIPE} Terms of Reference",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1181,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1990,
ABSTRACT="This RFC describes the Terms of Reference of RIPE (Reseaux IP
Europeens), the cooperation of European IP networks. This memo provides
information for the Internet community. It does not specify any
standard.",
URL="http://www.rfc-editor.org/rfc/rfc1181.txt"
}

@TECHREPORT{rfc1183,
AUTHOR="C. Everhart and L. A. Mamakos and R. Ullmann and P. V. Mockapetris",
TITLE="New {DNS} {RR} Definitions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1183,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1990,
ABSTRACT="This memo defines five new DNS types for experimental
purposes. This RFC describes an Experimental Protocol for the Internet
community, and requests discussion and suggestions for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc1183.txt"
}

@TECHREPORT{rfc1184,
AUTHOR="David A. Borman",
TITLE="Telnet Linemode Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1184,
PAGES=23,
DAYS=15,
MONTH=oct,
YEAR=1990,
ABSTRACT="This RFC specifies a procedure for line at a time terminal
interaction based on the Telnet Protocol. It obsoletes RFC 1116.",
URL="http://www.rfc-editor.org/rfc/rfc1184.txt"
}

@TECHREPORT{rfc1185,
AUTHOR="V. Jacobson and R. Braden and L. Zhang",
TITLE="{TCP} Extension for {High-Speed} Paths",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1185,
PAGES=21,
DAYS=15,
MONTH=oct,
YEAR=1990,
ABSTRACT={This memo describes an Experimental Protocol extension to TCP
for the Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the {"}IAB Official
Protocol Standards{"} for the standardization state and status of this
protocol.},
URL="http://www.rfc-editor.org/rfc/rfc1185.txt"
}

@TECHREPORT{rfc1186,
AUTHOR="Ronald L. Rivest",
TITLE="{MD4} Message Digest Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1186,
PAGES=18,
DAYS=15,
MONTH=oct,
YEAR=1990,
ABSTRACT="This RFC is the specification of the MD4 Digest Algorithm. If
you are going to implement MD4, it is suggested you do it this way. This
memo is for informational use and does not constitute a standard.",
URL="http://www.rfc-editor.org/rfc/rfc1186.txt"
}

@TECHREPORT{rfc1187,
AUTHOR="Marshall T. Rose and K. McCloghrie and J. R. Davin",
TITLE="Bulk Table Retrieval with the {SNMP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1187,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=1990,
ABSTRACT={This memo reports an interesting family of algorithms for bulk
table retrieval using the Simple Network Management Protocol (SNMP).
This memo describes an Experimental Protocol for the Internet community,
and requests discussion and suggestions for improvements. This memo does
not specify a standard for the Internet community. Please refer to the
current edition of the {"}IAB Official Protocol Standards{"} for the
standardization state and status of this protocol.},
URL="http://www.rfc-editor.org/rfc/rfc1187.txt"
}

@TECHREPORT{rfc1188,
AUTHOR="D. Katz",
TITLE="Proposed Standard for the Transmission of {IP} Datagrams over {FDDI}
Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1188,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1990,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1188.txt"
}

@TECHREPORT{rfc1189,
AUTHOR="U. Warrier and L. Besaw and L. LaBarre and B. D. Handspicker",
TITLE="Common Management Information Services and Protocols for the Internet
{(CMOT} and {CMIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1189,
PAGES=15,
DAYS=15,
MONTH=oct,
YEAR=1990,
ABSTRACT="This memo defines a network management architecture that uses
the International Organization for Standardization's (ISO) Common
Management Information Services/Common Management Information Protocol
(CMIS/CMIP) in the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1189.txt"
}

@TECHREPORT{rfc1190,
AUTHOR="C. Topolcic",
TITLE="Experimental Internet Stream Protocol: Version 2 {(ST-II)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1190,
PAGES=148,
DAYS=15,
MONTH=oct,
YEAR=1990,
ABSTRACT={This memo defines a revised version of the Internet Stream
Protocol, originally defined in IEN-119, based on results from
experiments with the original version, and subsequent requests,
discussion, and suggestions for improvements. This is a Limited-Use
Experimental Protocol. Please refer to the current edition of the {"}IAB
Official Protocol Standards{"} for the standardization state and status of
this protocol.},
URL="http://www.rfc-editor.org/rfc/rfc1190.txt"
}

@TECHREPORT{rfc1191,
AUTHOR="J. C. Mogul and S. E. Deering",
TITLE="Path {MTU} discovery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1191,
PAGES=19,
DAYS=15,
MONTH=nov,
YEAR=1990,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1191.txt"
}

@TECHREPORT{rfc1192,
AUTHOR="B. Kahin",
TITLE="Commercialization of the Internet summary report",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1192,
PAGES=13,
DAYS=15,
MONTH=nov,
YEAR=1990,
ABSTRACT="This memo is based on a workshop held by the Science,
Technology and Public Policy Program of the John F. Kennedy School of
Government, Harvard University, March 1-3, 1990. This memo provides
information for the Internet community. It does not specify any
standard.",
URL="http://www.rfc-editor.org/rfc/rfc1192.txt"
}

@TECHREPORT{rfc1193,
AUTHOR="D. Ferrari",
TITLE="Client requirements for real-time communication services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1193,
PAGES=24,
DAYS=15,
MONTH=nov,
YEAR=1990,
ABSTRACT="This memo describes client requirements for real-time
communication services. This memo provides information for the Internet
community, and requests discussion and suggestions for improvements. It
does not specify any standard. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1193.txt"
}

@TECHREPORT{rfc1194,
AUTHOR="D. Patrick Zimmerman",
TITLE="Finger User Information Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1194,
PAGES=12,
DAYS=15,
MONTH=nov,
YEAR=1990,
ABSTRACT="This memo describes the Finger User Information Protocol. This
is a simple protocol which provides an interface to a remote user
information program. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1194.txt"
}

@TECHREPORT{rfc1195,
AUTHOR="R. Callon",
TITLE="Use of {OSI} {IS-IS} for routing in {TCP/IP} and dual environments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1195,
PAGES=85,
DAYS=15,
MONTH=dec,
YEAR=1990,
ABSTRACT="This memo 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.",
URL="http://www.rfc-editor.org/rfc/rfc1195.txt"
}

@TECHREPORT{rfc1196,
AUTHOR="D. Patrick Zimmerman",
TITLE="The Finger User Information Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1196,
MONTH=dec,
YEAR=1990,
ABSTRACT="1.1. Intent",
URL="http://www.rfc-editor.org/rfc/rfc1196.txt"
}

@TECHREPORT{rfc1197,
AUTHOR="M. Sherman",
TITLE="Using {ODA} for translating multimedia information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1197,
PAGES=2,
DAYS=15,
MONTH=dec,
YEAR=1990,
ABSTRACT="The purpose of this RFC is to inform implementors of
multimedia systems about our experiences using ISO 8613: Office Document
Architecture (ODA). Because ODA is being proposed as an encoding format
for use in multimedia mail and file exchange, implementors wishing to
use ODA in an open systems environment may profit from our experiences.
This memo provides information for the Internet community. It does not
specify any standard.",
URL="http://www.rfc-editor.org/rfc/rfc1197.txt"
}

@TECHREPORT{rfc1099,
AUTHOR="J. F. Reynolds",
TITLE="Request for Comments Summary: {RFC} Numbers {1000-1099}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1099,
PAGES=22,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT="This memo is a slightly annotated list of the 100 RFCs from
RFC 1000 through RFCs 1099.",
URL="http://www.rfc-editor.org/rfc/rfc1099.txt"
}

@TECHREPORT{rfc1108,
AUTHOR="Stephen T. Kent",
TITLE="{U.S.} Department of Defense Security Options for the Internet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1108,
MONTH=nov,
YEAR=1991,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1108.txt"
}

@TECHREPORT{rfc1170,
AUTHOR="R. B. Fougner",
TITLE="Public key standards and licenses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1170,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1991,
ABSTRACT="This RFC is a public statement by Public Key Partners
regarding Public Key Standards and Licenses. This memo is for
informational use only, and does not constitute an Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc1170.txt"
}

@TECHREPORT{rfc1180,
AUTHOR="T. J. Socolofsky and C. J. Kale",
TITLE="{TCP/IP} tutorial",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1180,
PAGES=28,
DAYS=15,
MONTH=jan,
YEAR=1991,
ABSTRACT="This RFC is a tutorial on the TCP-IP protocol suite, focusing
particularly on the steps in forwarding an IP datagram from source host
to destination host through a router. It does not specify an Internet
standard.",
URL="http://www.rfc-editor.org/rfc/rfc1180.txt"
}

@TECHREPORT{rfc1198,
AUTHOR="R. Scheifler",
TITLE="{FYI} on the X window system",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1198,
PAGES=3,
DAYS=15,
MONTH=jan,
YEAR=1991,
ABSTRACT="This FYI RFC provides pointers to the published standards of
the MIT X Consortium. This memo provides information for the Internet
community. It does not specify any Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc1198.txt"
}

@TECHREPORT{rfc1199,
AUTHOR="J. F. Reynolds",
TITLE="Request for Comments Summary Notes: {1100-1199}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1199,
PAGES=22,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1100 through RFCs 1199. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1199.txt"
}

@TECHREPORT{rfc1200,
AUTHOR="J. B. Postel",
TITLE="{IAB} official protocol standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1200,
PAGES=31,
DAYS=15,
MONTH=apr,
YEAR=1991,
ABSTRACT="Discussion of the standardization process and the RFC document
series is presented first, followed by an explanation of the terms.
Sections 6.2 - 6.8 contain the lists of protocols in each stage of
standardization. Finally come pointers to references and contacts for
further information. This memo is intended to be issued quarterly;
please be sure the copy you are reading is current. Current copies may
be obtained from the Network Information Center or from the Internet
Assigned Numbers Authority (see the contact information at the end of
this memo). Do not use this edition after 30-Jun-91. See Section 6.1 for
a description of recent changes. In the official lists in sections 6.2 -
6.8, an asterisk (*) next to a protocol denotes that it is new to this
document or has been moved from one protocol level to another.",
URL="http://www.rfc-editor.org/rfc/rfc1200.txt"
}

@TECHREPORT{rfc1201,
AUTHOR="D. Provan",
TITLE="Transmitting {IP} traffic over {ARCNET} networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1201,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1991,
ABSTRACT={This memo specifies a method of encapsulating Internet
Protocol (IP) and Address Resolution Protocol (ARP) datagrams for
transmission across ARCNET using the {"}ARCNET Packet Header Definition
Standard{"}. This memo offers a replacement for RFC 1051. RFC 1051 uses an
ARCNET framing protocol which limits unfragmented IP packets to 508
octets.},
URL="http://www.rfc-editor.org/rfc/rfc1201.txt"
}

@TECHREPORT{rfc1202,
AUTHOR="Marshall T. Rose",
TITLE="Directory Assistance service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1202,
PAGES=11,
DAYS=15,
MONTH=feb,
YEAR=1991,
ABSTRACT="The OSI Directory provides a powerful infrastructure for the
retrieval of information objects. This infrastructure can be used to
support, e.g., white pages applications, application entity lookup, and
so on.",
URL="http://www.rfc-editor.org/rfc/rfc1202.txt"
}

@TECHREPORT{rfc1203,
AUTHOR="J. Rice",
TITLE="Interactive Mail Access Protocol: Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1203,
PAGES=49,
DAYS=15,
MONTH=feb,
YEAR=1991,
ABSTRACT={The intent of the Interactive Mail Access Protocol, Version 3
(IMAP3) is to allow a (possibly unreliable) workstation or similar
machine to access electronic mail from a reliable mailbox server in an
efficient manner. Although different in many ways from POP2 (RFC 937),
IMAP3 may be thought of as a functional superset of POP2, and the POP2
RFC was used as a model for this RFC. There was a cognizant reason for
this; RFC 937 deals with an identical problem and it was desirable to
offer a basis for comparison. Like POP2, IMAP3 specifies a means of
accessing stored mail and not of posting mail; this function is handled
by a mail transfer protocol such as SMTP (RFC 821). A comparison with
the DMSP protocol of PCMAIL can be found at the end of {"}System Model and
Philosophy{"} section. This protocol assumes a reliable data stream such
as provided by TCP or any similar protocol. When TCP is used, the IMAP
server listens on port 220. When CHAOS is used the IMAP server listens
for the logical contact name {"}IMAP3{"}. Communication in IMAP is defined
to be using the ASCII character interpretation of data. Communication
using other conventions may be possible by the selection of features on
some servers.},
URL="http://www.rfc-editor.org/rfc/rfc1203.txt"
}

@TECHREPORT{rfc1204,
AUTHOR="S. Yeh and D. Lee",
TITLE="Message Posting Protocol {(MPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1204,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1991,
ABSTRACT="Operating systems for personal computers do not provide a
mechanism for user authentication. However, such a mechanism is crucial
for electronic mail system since authenticating message sender's
identity is important in preventing mail forgery. Hence, adding personal
computers to an electronic mail network requires an agent (message
posting server) to authenticate sender's identity and then submit mail
to the message delivery system (e.g., Sendmail, MMDF) on behalf of the
sender at a PC. The Netix Message Posting Protocol is developed to be
the interface between the message posting server and the PC (client).
The protocol is designed to use TCP and is based on the command and
reply structures defined for Simple Mail Transfer Protocol (RFC 821) and
File Transfer Protocol (RFC 959).",
URL="http://www.rfc-editor.org/rfc/rfc1204.txt"
}

@TECHREPORT{rfc1205,
AUTHOR="P. Chmielewski",
TITLE="5250 Telnet interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1205,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=1991,
ABSTRACT="This RFC describes the interface to the IBM 5250 Telnet
implementation. The purpose of this memo is to describe the details of
the interface so that a person wanting to implement a client Telnet
which emulates an IBM 5250 work station would be able to do so. This
memo does not describe all of the 5250 commands, aid codes, and other
information specific to the 5250 data stream. That information is
contained in the IBM 5250 Information Display System, Functions
Reference Manual, IBM publication number SA21-9247. Corrections and
additions to this manual are documented in this RFC in section 5.",
URL="http://www.rfc-editor.org/rfc/rfc1205.txt"
}

@TECHREPORT{rfc1206,
AUTHOR="Gary Scott Malkin and A. N. Marine",
TITLE={{FYI} on Questions and Answers: Answers to commonly asked {"}new Internet
user{"} questions},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1206,
PAGES=32,
DAYS=15,
MONTH=feb,
YEAR=1991,
ABSTRACT="New users joining the Internet community have the same
questions as did everyone else who has ever joined. Our quest is to
provide the Internet community with up to date, basic Internet knowledge
and experience, while moving the redundancies away from the electronic
mailing lists so that the lists' subscribers do not have to read the
same queries and answers over and over again. Future updates of this
memo will be produced as User Services members",
URL="http://www.rfc-editor.org/rfc/rfc1206.txt"
}

@TECHREPORT{rfc1207,
AUTHOR="Gary Scott Malkin and A. N. Marine and J. F. Reynolds",
TITLE={{FYI} on Questions and Answers: Answers to commonly asked {"}experienced
Internet user{"} questions},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1207,
PAGES=15,
DAYS=15,
MONTH=feb,
YEAR=1991,
ABSTRACT="During the last few months, several people have monitored
various major mailing lists and have extracted questions that are
important or commonly asked. This FYI RFC is one of two in a series of
FYI's which present the questions and their answers. The first FYI, FYI
4, presented questions new Internet users commonly ask and their
answers.",
URL="http://www.rfc-editor.org/rfc/rfc1207.txt"
}

@TECHREPORT{rfc1208,
AUTHOR="Ole J. Jacobsen and Dan Lynch",
TITLE="Glossary of networking terms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1208,
PAGES=18,
DAYS=15,
MONTH=mar,
YEAR=1991,
ABSTRACT={This glossary is adapted from {"}The INTEROP Pocket Glossary of
Networking Terms{"} produced to help you understand the many terms--and in
particular the myriad of acronyms--that can be encountered at the
INTEROP Tutorials, Conference, and Exhibition. To keep this document
reasonably small we have deliberately omitted common computer and
communications terms such as disk, modem, byte, and VLSI. In addition,
the definitions have been kept brief. We recommend that you consult the
glossaries found in the major computer networking textbooks for more
comprehensive definitions. We also realize that producing this glossary
is akin to shooting at a moving target. The computer and communications
industries are moving very rapidly, and terms and acronyms are born
every day. You are invited to submit words which you think should be
included in future editions.},
URL="http://www.rfc-editor.org/rfc/rfc1208.txt"
}

@TECHREPORT{rfc1209,
AUTHOR="D. Piscitello and J. Lawrence",
TITLE="Transmission of {IP} datagrams over the {SMDS} Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1209,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1209.txt"
}

@TECHREPORT{rfc1210,
AUTHOR="V. G. Cerf and P. T. Kirstein and B. Randell",
TITLE="Network and infrastructure user requirements for transatlantic research
collaboration: Brussels, July {16-18,} and Washington July {24-25,} 1990",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1210,
PAGES=36,
DAYS=15,
MONTH=mar,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1210.txt"
}

@TECHREPORT{rfc1211,
AUTHOR="A. Westine and J. B. Postel",
TITLE="Problems with the maintenance of large mailing lists",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1211,
PAGES=54,
DAYS=15,
MONTH=mar,
YEAR=1991,
ABSTRACT="Maintaining large mailing lists, especially the processing of
error reports, poses many problems. Most of the examples come from the
experience of managing the Internet Engineering Task Force (IETF)
mailing list. Many examples are presented in this memo. Most of the
specific problems shown have already been corrected.",
URL="http://www.rfc-editor.org/rfc/rfc1211.txt"
}

@TECHREPORT{rfc1212,
AUTHOR="Marshall T. Rose and K. McCloghrie",
TITLE="Concise {MIB} definitions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1212,
PAGES=19,
DAYS=15,
MONTH=mar,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1212.txt"
}

@TECHREPORT{rfc1213,
AUTHOR="K. McCloghrie and Marshall T. Rose",
TITLE="Management Information Base for Network Management of {TCP/IP-based}
{internets:MIB-II}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1213,
PAGES=70,
DAYS=15,
MONTH=mar,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1213.txt"
}

@TECHREPORT{rfc1214,
AUTHOR="L. LaBarre",
TITLE="{OSI} internet management: Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1214,
PAGES=83,
DAYS=15,
MONTH=apr,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1214.txt"
}

@TECHREPORT{rfc1215,
AUTHOR="Marshall T. Rose",
TITLE="Convention for defining traps for use with the {SNMP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1215,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1991,
ABSTRACT="This memo suggests a straight-forward approach towards
defining traps used with the SNMP. Readers should note that the use of
traps in the Internet-standard network management framework is
controversial. As such, this memo is being put forward for information
purposes. Network management practitioners who employ traps are
encouraged to make use of this document. Practitioners who do not employ
traps can safely ignore this document.",
URL="http://www.rfc-editor.org/rfc/rfc1215.txt"
}

@TECHREPORT{rfc1216,
AUTHOR="P. Richard and P. Kynikos",
TITLE="Gigabit network economics and paradigm shifts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1216,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1991,
ABSTRACT="The history of computer communication contains many examples
of efforts to align the capabilities of processors to that of
communication media. Packet switching is the classic case of a careful
tradeoff between the costs of memory, processing, and communications
bandwidth. With all of the attention and publicity focused on gigabit
networks, not much notice has been given to small and largely unfunded
research efforts which are studying innovative approaches for dealing
with technical issues within the constraints of economic science. This
memo defines one such paradigm.",
URL="http://www.rfc-editor.org/rfc/rfc1216.txt"
}

@TECHREPORT{rfc1217,
AUTHOR="V. G. Cerf",
TITLE="Memo from the Consortium for Slow Commotion Research {(CSCR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1217,
PAGES=5,
DAYS=15,
MONTH=apr,
YEAR=1991,
ABSTRACT="Military requirements place a high premium on ultra-robust
systems capable of supporting communication in extremely hostile
environments. A major contributing factor in the survivability of
systems is a high degree of redundancy. CSCR believes that the system
designs offered below exhibit extraordinary redundancy features which
should be of great interest to DARPA and the Department of Defense.",
URL="http://www.rfc-editor.org/rfc/rfc1217.txt"
}

@TECHREPORT{rfc1218,
AUTHOR=" {{North American Directory Forum}}",
TITLE="Naming scheme for {c=US}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1218,
MONTH=apr,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1218.txt"
}

@TECHREPORT{rfc1219,
AUTHOR="Paul F. Tsuchiya",
TITLE="On the assignment of subnet numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1219,
PAGES=13,
DAYS=15,
MONTH=apr,
YEAR=1991,
ABSTRACT={RFC-950 specifies a procedure for subnetting Internet
addresses using a bit-mask. While RFC-950 allows the {"}ones{"} in the
subnet mask to be non-contiguous, RFC-950 recommends that 1) they be
contiguous, and 2) that they occupy the most significant bits of the
{"}host{"} part of the internet address. RFC-950 did not specify whether
different subnets of the same network may have different masks. This
ambiguity was unfortunate, as it resulted in development of routing
protocols that do not support different masks; see e.g., RIP. The
Gateway Requirements RFC settled the issue in favor of allowing
different masks, and therefore future routing protocols may be expected
to support this feature; OSPF is an example. The network administrator
must of course determine the mask for each subnet. This involves making
an estimate of how many hosts each subnet is expected to have. As it is
often impossible to predict how large each subnet will grow, inefficient
choices are often made, with some subnets under-utilized, and others
possibly requiring renumbering because of exceeded capacity. This memo
specifies a procedure for assigning subnet numbers that eliminates the
need to estimate subnet size. Essentially, host bits (mask = 0) are
assigned from the least significant bit working towards the most, and
subnet bits (mask = 1) are assigned from the most significant bit
working towards the least. As subnets grow, more host bits are assigned.
As the number of subnets grows, more subnet bits are assigned. While
this process does sometimes result},
URL="http://www.rfc-editor.org/rfc/rfc1219.txt"
}

@TECHREPORT{rfc1220,
AUTHOR="F. Baker",
TITLE="{Point-to-Point} Protocol extensions for bridging",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1220,
PAGES=18,
DAYS=15,
MONTH=apr,
YEAR=1991,
ABSTRACT="This document defines an extension of the Internet
Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use
of Point-to-Point lines for Remote Bridging.",
URL="http://www.rfc-editor.org/rfc/rfc1220.txt"
}

@TECHREPORT{rfc1221,
AUTHOR="W. Edmond",
TITLE="Host Access Protocol {(HAP)} specification: Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1221,
PAGES=68,
DAYS=15,
MONTH=apr,
YEAR=1991,
ABSTRACT={The Host Access Protocol (HAP) is a network layer protocol (as
is X.25). ({"}Network layer{"} here means ISO layer 3 lower, the protocol
layer below the DoD Internet Protocol (IP) layer and above any link
layer protocol.) HAP defines the different types of host-to- network
control messages and host-to-host data messages that may be exchanged
over the access link connecting a host and the network packet switch
node. The protocol establishes formats for these messages, and describes
procedures for determining when each type of message should be
transmitted and what it means when one is received. HAP has been
implemented in the wide-area network called the Terrestrial Wideband
Network (TWBNET) and in the routers and other hosts that connect to
TWBNET. The packet switch nodes that compose the TWBNET are called
Wideband Packet Switches (WPS). Both the precursor to HAP, the
Host/SATNET Protocol, used in the Atlantic Packet Satellite Network
(SATNET) and the Mobile Access Terminal Network (MATNET), and HAP, used
in the original Wideband Satellite Network (WBNET), were originally
designed to provide efficient access to the single satellite channel
each network used to connect all sites. The HAP protocol designers
reflected some of the peculiarities of the single satellite channel
environment in the HAP protocol itself. The current Terrestrial Wideband
Network (TWBNET) utilizes T1-speed fiber connections between sites.
Future networks and TWBNET may use a combination of terrestrial
connections and satellite connections, and may have more than one of
each. The HAP protocol has been changed to accommodate these extensions.
Section 2 presents an overview of HAP. Details of HAP formats and
message exchange procedures are contained in Sections 3 through 10.
Further explanation of some of the topics addressed in this HAP
specification can be found elsewhere. Any protocol employed to provide
sufficiently reliable message exchange over the Host-WPS link is assumed
to be transparent to the protocol defined in this document. Examples of
such link-level protocols are ARPANET 1822 local and distant host,
ARPANET VDH protocol, and HDLC.},
URL="http://www.rfc-editor.org/rfc/rfc1221.txt"
}

@TECHREPORT{rfc1222,
AUTHOR="H. Braun and Y. Rekhter",
TITLE="Advancing the {NSFNET} routing architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1222,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="This memo describes the history of NSFNET Backbone routing and
outlines two suggested phases for further evolution of the Backbone's
routing interface. The intent is to provide a more flexible interface
for NSFNET Backbone service subscribers, by providing an attachment
option that is simpler and lower-cost than the current one.",
URL="http://www.rfc-editor.org/rfc/rfc1222.txt"
}

@TECHREPORT{rfc1223,
AUTHOR="J. Y. Halpern",
TITLE="{OSI} {CLNS} and {LLC1} protocols on Network Systems {HYPERchannel}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1223,
PAGES=12,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="The intent of this document is to provide a complete
discussion of the protocols and techniques used to transmit OSI CLNS and
LLC1 datagrams (and any associated higher level protocols) on Network
Systems Corporation's HYPERchannel equipment. This document is intended
for network planners and implementers who are already familiar with the
OSI protocol suite and the techniques used to carry OSI traffic on
standard networks such as 802.3.",
URL="http://www.rfc-editor.org/rfc/rfc1223.txt"
}

@TECHREPORT{rfc1224,
AUTHOR="L. Steinberg",
TITLE="Techniques for managing asynchronously generated alerts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1224,
PAGES=22,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1224.txt"
}

@TECHREPORT{rfc1225,
AUTHOR="Marshall T. Rose",
TITLE="Post Office Protocol: Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1225,
PAGES=16,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="This memo is a republication of RFC 1081 which was based on
RFC 918 (since revised as RFC 937). Although similar in form to the
original Post Office Protocol (POP) proposed for the Internet community,
the protocol discussed in this memo is similar in spirit to the ideas
investigated by the MZnet project at the University of California,
Irvine. Further, substantial work was done on examining POP in a
PC-based environment. This work, which resulted in additional
functionality in this protocol, was performed by the ACIS Networking
Systems Group at Stanford University. The author gratefully acknowledges
their interest.",
URL="http://www.rfc-editor.org/rfc/rfc1225.txt"
}

@TECHREPORT{rfc1226,
AUTHOR="B. Kantor",
TITLE="Internet protocol encapsulation of {AX.25} frames",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1226,
PAGES=2,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="This memo describes a method for the encapsulation of AX.25
(the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets.
This technique is an Experimental Protocol for the Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc1226.txt"
}

@TECHREPORT{rfc1227,
AUTHOR="Marshall T. Rose",
TITLE="{SNMP} {MUX} protocol and {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1227,
PAGES=13,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="On typical kernel/user systems, an agent speaking the SNMP is
often implemented as a user-process, that reads kernel variables in
order to realize the Internet-standard MIB. This approach works fine as
long as all of the information needed by the SNMP agent resides in
either the kernel or in stable storage (i.e., files). However, when
other user-processes are employed to implement other",
URL="http://www.rfc-editor.org/rfc/rfc1227.txt"
}

@TECHREPORT{rfc1228,
AUTHOR="G. A. Carpenter and B. Wijnen",
TITLE="{SNMP-DPI:} Simple Network Management Protocol Distributed Program
Interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1228,
PAGES=50,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="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. For the author of a
sub-agent, the SNMP-DPI eliminates the need to know the details of ASN.1
or SNMP PDU (Protocol Data Unit) encoding/decoding. This protocol has
been in use within IBM since 1989 and is included in the SNMP agents for
VM, MVS and OS/2. Potentially useful sample sub-agent code and
implementation examples are available for anonymous FTP from the
University of Toronto.",
URL="http://www.rfc-editor.org/rfc/rfc1228.txt"
}

@TECHREPORT{rfc1229,
AUTHOR="K. McCloghrie",
TITLE="Extensions to the generic-interface {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1229,
PAGES=16,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1229.txt"
}

@TECHREPORT{rfc1230,
AUTHOR="K. McCloghrie and R. Fox",
TITLE="{IEEE} {802.4} Token Bus {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1230,
PAGES=23,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1230.txt"
}

@TECHREPORT{rfc1231,
AUTHOR="K. McCloghrie and R. Fox and E. Decker",
TITLE="{IEEE} {802.5} Token Ring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1231,
PAGES=23,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1231.txt"
}

@TECHREPORT{rfc1232,
AUTHOR="F. Baker and C. P. Kolb",
TITLE="Definitions of managed objects for the {DS1} Interface type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1232,
PAGES=28,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1232.txt"
}

@TECHREPORT{rfc1233,
AUTHOR="T. F. Cox and K. Tesink",
TITLE="Definitions of managed objects for the {DS3} Interface type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1233,
PAGES=23,
DAYS=15,
MONTH=may,
YEAR=1991,
ABSTRACT="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",
URL="http://www.rfc-editor.org/rfc/rfc1233.txt"
}

@TECHREPORT{rfc1234,
AUTHOR="D. Provan",
TITLE="Tunneling {IPX} traffic through {IP} networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1234,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1991,
ABSTRACT="Internet Packet eXchange protocol (IPX) is the internetwork
protocol used by Novell's NetWare protocol suite. For the purposes of
this paper, IPX is functionally equivalent to the Internet Datagram
Protocol (IDP) from the Xerox Network Systems (XNS) protocol suite. This
memo describes a method of encapsulating IPX datagrams within UDP
packets so that IPX traffic can travel across an IP internet. This RFC
allows an IPX implementation to view an IP internet as a single IPX
network. An implementation of this memo will encapsulate IPX datagrams
in UDP packets in the same way any hardware implementation might
encapsulate IPX datagrams in that hardware's frames. IPX networks can be
connected thusly across internets that carry only IP traffic.",
URL="http://www.rfc-editor.org/rfc/rfc1234.txt"
}

@TECHREPORT{rfc1235,
AUTHOR="J. Ioannidis and Gerald (Chip) Maguire",
TITLE="Coherent File Distribution Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1235,
PAGES=12,
DAYS=15,
MONTH=jun,
YEAR=1991,
ABSTRACT={The Coherent File Distribution Protocol (CFDP) has been
designed to speed up one-to-many file transfer operations that exhibit
traffic coherence on media with broadcast capability. Examples of such
coherent file transfers are identical diskless workstations booting
simultaneously, software upgrades being distributed to more than one
machines at a site, a certain {"}object{"} (bitmap, graph, plain text,
etc.)
that is being discussed in a real-time electronic conference or class
being sent to all participants, and so on. In all these cases, we have a
limited number of servers, usually only one, and <n> clients (where <n>
can be large) that are being sent the same file. If these files are sent
via multiple one-to-one transfers, the load on both the server and the
network is greatly increased, as the same data are sent <n> times. We
propose a file distribution protocol that takes advantage of the
broadcast nature of the communications medium (e.g., fiber, ethernet,
packet radio) to drastically reduce the time needed for file transfer
and the impact on the file server and the network. While this protocol
was developed to allow the simultaneous booting of diskless workstations
over our experimental packet-radio network, it can be used in any
situation where coherent transfers take place. CFDP was originally
designed as a back-end protocol; a front-end interface (to convert file
names and requests for them to file handles) is still needed, but a
number of existing protocols can be adapted to use with CFDP. Two such
reference applications have been developed; one is for diskless booting
of workstations, a simplified},
URL="http://www.rfc-editor.org/rfc/rfc1235.txt"
}

@TECHREPORT{rfc1236,
AUTHOR="L. Morales and P. Hasse",
TITLE="{IP} to {X.121} address mapping for {DDN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1236,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1991,
ABSTRACT="This memo defines a standard way of converting IP addresses to
CCITT X.121 addresses and is the recommended standard for use on the
Internet, specifically for the Defense Data Network (DDN).",
URL="http://www.rfc-editor.org/rfc/rfc1236.txt"
}

@TECHREPORT{rfc1237,
AUTHOR="R. Colella and E. Gardner and R. Callon",
TITLE="Guidelines for {OSI} {NSAP} Allocation in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1237,
PAGES=49,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1237.txt"
}

@TECHREPORT{rfc1238,
AUTHOR="G. Satz",
TITLE="{CLNS} {MIB} for use with Connectionless Network Protocol {(ISO} {8473)}
and End System to Intermediate System {(ISO} {9542)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1238,
PAGES=32,
DAYS=15,
MONTH=jun,
YEAR=1991,
ABSTRACT="This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets.",
URL="http://www.rfc-editor.org/rfc/rfc1238.txt"
}

@TECHREPORT{rfc1239,
AUTHOR="J. F. Reynolds",
TITLE="Reassignment of experimental {MIBs} to standard {MIBs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1239,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1991,
ABSTRACT="In the past, MIBs have been assigned arcs in the experimental
MIB namespace early in their development and then were not assigned arcs
in the standard MIB namespace until they reached Full Standard status.
This practice required vendors to revise their implementations when a
MIB went from Draft to Full Standard status, even though there was
probably no substantive technical change in the definitions. This
practice could also engender operational problems in the field at an
undesirably late stage of the standardization process. It was also
observed that this practice could discourage implementation until the
Full Standard stage and that this, too, would be undesirable. So, a
preferable practice is to assign arcs in the standard MIB namespace at
the earliest phase of standardization and to preserve these assignments
as the standard progresses.",
URL="http://www.rfc-editor.org/rfc/rfc1239.txt"
}

@TECHREPORT{rfc1240,
AUTHOR="C. Shue and W. Haggerty and K. Dobbins",
TITLE="{OSI} connectionless transport services on top of {UDP:} Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1240,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=1991,
ABSTRACT="The Internet community has a well-developed, mature set of
layered transport and network protocols, which are quite successful in
offering both connection-oriented (TCP) and connectionless (UDP)
transport services over connectionless network services (IP) to end-
users. Many popular network applications have been built directly on top
of the TCP and UDP over the past decade. These have helped the Internet
services and protocols to become widely-spread de facto standards. In
the past few years, the ISO and CCITT have defined a well-architected
set of upper layer standards which include connection-oriented and
connectionless session, presentation, and application layer services and
protocols. These OSI upper layer standards offer valuable services to
application developers (e.g., dialogue control, transfer syntax, peer
authentication, directory services, etc.) which are not currently
offered by the TCP/IP standards. As indicated in RFC 1006, it is
desirable to offer the OSI upper layer services directly in the Internet
without disrupting existing facilities. This permits a more graceful
convergence and transition strategy from IP-based networks to OSI-based
networks in the future. Using the approach of RFC 1006, this memo
specifies how to offer OSI connectionless transport service using the
User Datagram Protocol (UDP) (RFC768) of the TCP/IP suite. We will
define a Transport Service Access Point (TSAP) which appears",
URL="http://www.rfc-editor.org/rfc/rfc1240.txt"
}

@TECHREPORT{rfc1241,
AUTHOR="R. A. Woodburn and D. L. Mills",
TITLE="Scheme for an internet encapsulation protocol: Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1241,
PAGES=17,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT={For several years researchers in the Internet community have
needed a means of {"}tunneling{"} between networks. A tunnel is essentially
a Source Route that circumvents conventional routing mechanisms. Tunnels
provide the means to bypass routing failures, avoid broken gateways and
routing domains, or establish deterministic paths for experimentation.},
URL="http://www.rfc-editor.org/rfc/rfc1241.txt"
}

@TECHREPORT{rfc1242,
AUTHOR="S. Bradner",
TITLE="Benchmarking terminology for network interconnection devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1242,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1242.txt"
}

@TECHREPORT{rfc1243,
AUTHOR="S. Waldbusser",
TITLE="{AppleTalk} Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1243,
PAGES=29,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing AppleTalk
networks.",
URL="http://www.rfc-editor.org/rfc/rfc1243.txt"
}

@TECHREPORT{rfc1244,
AUTHOR="J. P. Holbrook and J. F. Reynolds",
TITLE="Site Security Handbook",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1244,
PAGES=101,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT={This FYI RFC is a first attempt at providing Internet users
guidance on how to deal with security issues in the Internet. As such,
this document is necessarily incomplete. There are some clear
shortfalls; for example, this document focuses mostly on resources
available in the United States. In the spirit of the Internet's {"}Request
for Comments{"} series of notes, we encourage feedback from users of this
handbook. In particular, those who utilize this document to craft their
own policies and procedures. This handbook is meant to be a starting
place for further research and should be viewed as a useful resource,
but not the final authority. Different organizations and jurisdictions
will have different resources and rules. Talk to your local
organizations, consult an informed lawyer, or consult with local and
national law enforcement. These groups can help fill in the gaps that
this document cannot hope to cover.},
URL="http://www.rfc-editor.org/rfc/rfc1244.txt"
}

@TECHREPORT{rfc1245,
AUTHOR="J. Moy",
TITLE="{OSPF} Protocol Analysis",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1245,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT="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). 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1245.txt"
}

@TECHREPORT{rfc1246,
AUTHOR="J. Moy",
TITLE="Experience with the {OSPF} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1246,
PAGES=31,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT="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). 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. 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. Please send comments to ospf(at)trantor.umd.edu.",
URL="http://www.rfc-editor.org/rfc/rfc1246.txt"
}

@TECHREPORT{rfc1247,
AUTHOR="J. Moy",
TITLE="{OSPF} Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1247,
PAGES=189,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT="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. 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. Version 1 of the OSPF protocol was
documented in RFC 1131. The differences between the two versions are
explained in Appendix F. Please send comments to ospf(at)trantor.umd.edu.",
URL="http://www.rfc-editor.org/rfc/rfc1247.txt"
}

@TECHREPORT{rfc1248,
AUTHOR="F. Baker and R. Coltun",
TITLE="{OSPF} Version 2 Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1248,
PAGES=42,
DAYS=15,
MONTH=jul,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1248.txt"
}

@TECHREPORT{rfc1249,
AUTHOR="T. Howes and M. Smith and B. Beecher",
TITLE="{DIXIE} Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1249,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1991,
ABSTRACT="This RFC defines a mechanism by which TCP/UDP based clients
can access OSI Directory Service without the overhead of the ISO
transport and presentation protocols required to implement full-blown
DAP.",
URL="http://www.rfc-editor.org/rfc/rfc1249.txt"
}

@TECHREPORT{rfc1251,
AUTHOR="G. Malkin",
TITLE="Who's Who in the Internet: Biographies of {IAB,} {IESG} and {IRSG} Members",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1251,
PAGES=26,
DAYS=15,
MONTH=aug,
YEAR=1991,
ABSTRACT="There are thousands of networks in the internet. There are
tens of thousands of host machines. There are hundreds of thousands of
users. It takes a great deal of effort to manage the resources and
protocols which make the Internet possible. Sites may have people who
get paid to manage their hardware and software. But the infrastructure
of the Internet is managed by volunteers who spend considerable portions
of their valued time to keep the people connected. Hundreds of people
attend the three IETF meetings each year. They represent the government,
the military, research institutions, educational institutions, and
vendors from all over the world. Most of them are volunteers; people who
attend the meetings to learn and to contribute what they know. There are
a few very special people who deserve special notice. These are the
people who sit on the IAB, IESG, and IRSG. Not only do they spend time
at the meetings, but they spend additional time to organize them. They
are the IETF's interface to other standards bodies and to the funding
institutions. Without them, the IETF, indeed the whole Internet, would
not be possible.",
URL="http://www.rfc-editor.org/rfc/rfc1251.txt"
}

@TECHREPORT{rfc1254,
AUTHOR="Allison Mankin and K. G. Ramakrishnan",
TITLE="Gateway Congestion Control Survey",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1254,
PAGES=25,
DAYS=15,
MONTH=aug,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1254.txt"
}

@TECHREPORT{rfc1255,
AUTHOR=" {{North American Directory Forum}}",
TITLE="A Naming Scheme for {c=US}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1255,
MONTH=sep,
YEAR=1991,
ABSTRACT="This RFC is a near-verbatim copy of a document, known as
NADF-175, which has been produced by the North American Directory Forum
(NADF). The NADF is a collection of organizations which offer, or plan
to offer, public Directory services in North America, based on the CCITT
X.500 Recommendations. As a part of its charter, the NADF must reach
agreement as to how entries are named in the public portions of the
North American Directory. NADF-175 represents the NADF's agreement in
this area.",
URL="http://www.rfc-editor.org/rfc/rfc1255.txt"
}

@TECHREPORT{rfc1256,
EDITOR="S. E. Deering",
TITLE="{ICMP} Router Discovery Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1256,
PAGES=19,
DAYS=15,
MONTH=sep,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1256.txt"
}

@TECHREPORT{rfc1257,
AUTHOR="C. Partridge",
TITLE="Isochronous applications do not require jitter-controlled networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1257,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1257.txt"
}

@TECHREPORT{rfc1258,
AUTHOR="B. Kantor and Univ. {of Calif San Diego}",
TITLE="{BSD} Rlogin",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1258,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=1991,
ABSTRACT="The rlogin facility provides a remote-echoed, locally
flow-controlled virtual terminal with proper flushing of output. It is
widely used between Unix hosts because it provides transport of more of
the Unix terminal environment semantics than does the Telnet protocol,
and because on many Unix hosts it can be configured not to require user
entry of passwords when connections originate from trusted hosts.",
URL="http://www.rfc-editor.org/rfc/rfc1258.txt"
}

@TECHREPORT{rfc1259,
AUTHOR="M. Kapor",
TITLE="Building the open road: The {NREN} as test-bed for the national public
network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1259,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=1991,
ABSTRACT={A debate has begun about the future of America's
communications infrastructure. At stake is the future of the web of
information links organically evolving from computer and telephone
systems. By the end of the next decade, these links will connect nearly
all homes and businesses in the U.S. They will serve as the main
channels for commerce, learning, education, and entertainment in our
society. The new information infrastructure will not be created in a
single step: neither by a massive infusion of public funds, nor with the
private capital of a few tycoons, such as those who built the railroads.
Rather the national, public broadband digital network will emerge from
the {"}convergence{"} of the public telephone network, the cable television
distribution system, and other networks such as the Internet. The United
States Congress is now taking a critical step toward what I call the
National Public Network, with its authorization of the National Research
and Education Network (NREN, pronounced {"}en-ren{"}). Not only will the
NREN meet the computer and communication needs of scientists,
researchers, and educators, but also, if properly implemented, it could
demonstrate how a broadband network can be used in the future. As policy
makers debate the role of the public telephone and other existing
information networks in the nation's information infrastructure, the
NREN can serve as a working test-bed for new technologies, applications,
and governing policies that will ultimately shape the larger national
network. Congress has indicated its intention that the NREN would
provide American researchers and educators with the computer and
information resources they need, while demonstrating how advanced
computer, high speed networks, and electronic databases can improve the
national information infrastructure for use by all Americans.},
URL="http://www.rfc-editor.org/rfc/rfc1259.txt"
}

@TECHREPORT{rfc1261,
AUTHOR="S. Williamson and L. Nobile",
TITLE="Transition of Nic Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1261,
PAGES=3,
DAYS=15,
MONTH=sep,
YEAR=1991,
ABSTRACT="The transition of the Network Information Center from SRI
International in Menlo Park, CA, to Government Systems Inc. in
Chantilly, VA, is officially scheduled for 1 October 1991. This includes
the transition of services currently offered to DDN and Internet users
by SRI. These services include network/user registration (i.e., network
number and top level domain name assignment), on-line information
services, and Help Desk operations. GSI will also continue RFC and
Internet-Draft archive and distribution services.",
URL="http://www.rfc-editor.org/rfc/rfc1261.txt"
}

@TECHREPORT{rfc1262,
AUTHOR="V. G. Cerf",
TITLE="Guidelines for Internet Measurement Activities",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1262,
PAGES=3,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT="Measurement of the Internet is critical for future
development, evolution and deployment planning. Internet-wide activities
have the potential to interfere with normal operation and must be
planned with care and made widely known beforehand. This document offers
guidance to researchers planning Internet measurements.",
URL="http://www.rfc-editor.org/rfc/rfc1262.txt"
}

@TECHREPORT{rfc1263,
AUTHOR="S. O'Malley and L. L. Peterson",
TITLE="{TCP} Extensions Considered Harmful",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1263,
PAGES=19,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1263.txt"
}

@TECHREPORT{rfc1264,
AUTHOR="Robert Hinden",
TITLE="Internet Engineering Task Force Internet Routing Protocol Standardization
Criteria",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1264,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT="This informational RFC presents procedures for creating and
documenting Internet standards on routing protocols. These procedures
have been established by the Internet Activities Board (IAB) in
consultation with the Internet Engineering Steering Group (IESG).",
URL="http://www.rfc-editor.org/rfc/rfc1264.txt"
}

@TECHREPORT{rfc1265,
AUTHOR="Y. Rekhter",
TITLE="{BGP} Protocol Analysis",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1265,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT="The purpose of this report is to document how the requirements
for advancing a routing protocol to Draft Standard have been satisfied
by the Border Gateway Protocol (BGP). This report summarizes the key
feature of BGP, and analyzes the protocol with respect to scaling and
performance. This is the first of two reports on the BGP protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1265.txt"
}

@TECHREPORT{rfc1266,
AUTHOR="Y. Rekhter",
TITLE="Experience with the {BGP} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1266,
PAGES=9,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT={The purpose of this memo is to document how the requirements
for advancing a routing protocol to Draft Standard have been satisfied
by Border Gateway Protocol (BGP). This report documents experience with
BGP. This is the second of two reports on the BGP protocol. As required
by the Internet Activities Board (IAB) and the Internet Engineering
Steering Group (IESG), the first report will present a performance
analysis of the BGP protocol. The remaining sections of this memo
document how BGP satisfies General Requirements specified in Section
3.0, as well as Requirements for Draft Standard specified in Section 5.0
of the {"}Internet Routing Protocol Standardization Criteria{"} document.},
URL="http://www.rfc-editor.org/rfc/rfc1266.txt"
}

@TECHREPORT{rfc1267,
AUTHOR="K. Lougheed and Y. Rekhter",
TITLE="Border Gateway Protocol 3 {(BGP-3)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1267,
PAGES=35,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT={This memo, together with its companion document, {"}Application
of the Border Gateway Protocol in the Internet{"}, define an
inter-autonomous system routing protocol for the Internet.},
URL="http://www.rfc-editor.org/rfc/rfc1267.txt"
}

@TECHREPORT{rfc1268,
AUTHOR="Y. Rekhter and P. Gross",
TITLE="Application of the Border Gateway Protocol in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1268,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT={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. Information about the progress of BGP can be
monitored and/or reported on the BGP mailing list (iwg(at)rice.edu).},
URL="http://www.rfc-editor.org/rfc/rfc1268.txt"
}

@TECHREPORT{rfc1269,
AUTHOR="S. Willis and J. W. Burruss",
TITLE="Definitions of Managed Objects for the Border Gateway Protocol: Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1269,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the Border
Gateway Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1269.txt"
}

@TECHREPORT{rfc1270,
AUTHOR="F. Kastenholz",
TITLE="{SNMP} Communications Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1270,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1270.txt"
}

@TECHREPORT{rfc1271,
AUTHOR="S. Waldbusser",
TITLE="Remote Network Monitoring Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1271,
PAGES=81,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring devices.",
URL="http://www.rfc-editor.org/rfc/rfc1271.txt"
}

@TECHREPORT{rfc1272,
AUTHOR="C. B. Mills and D. Hirsh and Gregory Ruth",
TITLE="Internet Accounting: Background",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1272,
PAGES=19,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT={This document provides background information for the
{"}Internet Accounting Architecture{"}. The focus at this time is on
defining METER SERVICES and USAGE REPORTING which provide basic
semantics for measuring network utilization, a syntax, and a data
reporting protocol. The intent is to produce a set of standards that is
of practical use for early experimentation with usage reporting as an
internet accounting mechanism.},
URL="http://www.rfc-editor.org/rfc/rfc1272.txt"
}

@TECHREPORT{rfc1273,
AUTHOR="M. Schwartz",
TITLE="Measurement Study of Changes in {Service-Level} Reachability in the Global
{TCP/IP} Internet: Goals, Experimental Design, Implementation, and Policy
Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1273,
PAGES=8,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1273.txt"
}

@TECHREPORT{rfc1274,
AUTHOR="P. Barker and S. E. Kille",
TITLE="The {COSINE} and Internet {X.500} Schema",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1274,
PAGES=60,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="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. This document also proposes a mechanism for
allowing the schema to evolve in line with emerging requirements.
Proformas to support this process are included. Corrections and
additions to the schema should be sent to na- update(at)cs.ucl.ac.uk list,
as described within.",
URL="http://www.rfc-editor.org/rfc/rfc1274.txt"
}

@TECHREPORT{rfc1275,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="Replication Requirements to provide an Internet Directory using {X.500}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1275,
PAGES=3,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="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 additional protocol
or procedures for distributed operation.",
URL="http://www.rfc-editor.org/rfc/rfc1275.txt"
}

@TECHREPORT{rfc1276,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="Replication and Distributed Operations extensions to provide an Internet
Directory using {X.500}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1276,
PAGES=17,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1276.txt"
}

@TECHREPORT{rfc1277,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="Encoding Network Addresses to Support Operation over {Non-OSI} Lower Layers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1277,
PAGES=12,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="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:",
URL="http://www.rfc-editor.org/rfc/rfc1277.txt"
}

@TECHREPORT{rfc1278,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="A string encoding of Presentation Address",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1278,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="There are a number of environments where a simple string
encoding of Presentation Address is desirable. This specification
defines such a representation.",
URL="http://www.rfc-editor.org/rfc/rfc1278.txt"
}

@TECHREPORT{rfc1279,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="{X.500} and Domains",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1279,
PAGES=15,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1279.txt"
}

@TECHREPORT{rfc1281,
AUTHOR="R. Pethia and S. D. Crocker and B. Fraser",
TITLE="Guidelines for the Secure Operation of the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1281,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1991,
ABSTRACT="These guidelines address the entire Internet community,
consisting of users, hosts, local, regional, domestic and international
backbone networks, and vendors who supply operating systems, routers,
network management tools, workstations and other network components.
Security is understood to include protection of the privacy of
information, protection of information against unauthorized
modification, protection of systems against denial of service, and
protection of systems against unauthorized access. These guidelines
encompass six main points. These points are repeated and elaborated in
the next section. In addition, a bibliography of computer and network
related references has been provided at the end of this document for use
by the reader.",
URL="http://www.rfc-editor.org/rfc/rfc1281.txt"
}

@TECHREPORT{rfc1283,
AUTHOR="M. P. Rose",
TITLE="{SNMP} over {OSI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1283,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT="The Simple Network Management Protocol (SNMP) as defined in
RFC XXX is now used as an integral part of the network management
framework for TCP/IP-based internets. Together, with its companions
standards, which define the Structure of Management Information (SMI),
and the Management Information Base (MIB), the SNMP has received
widespread deployment in many operational networks running the Internet
suite of protocols. It should not be surprising that many of these sites
might acquire OSI capabilities and may wish to leverage their investment
in SNMP technology towards managing those OSI components. This memo
addresses these concerns by defining a framework for running the SNMP in
an environment which supports the OSI transport services.",
URL="http://www.rfc-editor.org/rfc/rfc1283.txt"
}

@TECHREPORT{rfc1284,
EDITOR="J. H. Cook",
TITLE="Definitions of Managed Objects for the Ethernet-like Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1284,
PAGES=21,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing ethernet-like
objects.",
URL="http://www.rfc-editor.org/rfc/rfc1284.txt"
}

@TECHREPORT{rfc1286,
AUTHOR="E. Decker and P. Langille and A. Rijsinghani and K. McCloghrie",
TITLE="Definitions of Managed Objects for Bridges",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1286,
PAGES=40,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular it defines objects for managing 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.",
URL="http://www.rfc-editor.org/rfc/rfc1286.txt"
}

@TECHREPORT{rfc1287,
AUTHOR="D. D. Clark and L. Chapin and V. G. Cerf and R. Braden and R. Hobby",
TITLE="Towards the Future Internet Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1287,
PAGES=29,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT="This informational RFC discusses important directions for
possible future evolution of the Internet architecture, and suggests
steps toward the desired goals.",
URL="http://www.rfc-editor.org/rfc/rfc1287.txt"
}

@TECHREPORT{rfc1288,
AUTHOR="D. Patrick Zimmerman",
TITLE="The Finger User Information Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1288,
PAGES=12,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT="This memo describes the Finger user information protocol. This
is a simple protocol which provides an interface to a remote user
information program. 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 RFC 1196.",
URL="http://www.rfc-editor.org/rfc/rfc1288.txt"
}

@TECHREPORT{rfc1289,
AUTHOR="J. Saperia",
TITLE="{DECnet} Phase {IV} {MIB} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1289,
PAGES=64,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1289.txt"
}

@TECHREPORT{rfc1290,
AUTHOR="J. Martin",
TITLE="There's Gold in them thar Networks! or Searching for Treasure in all the
Wrong Places",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1290,
PAGES=27,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT={This document was presented at the 1991 ACM SIGUCCS User
Services Conference. It appears here in its updated form. 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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1290.txt"
}

@TECHREPORT{rfc1291,
AUTHOR="V. Aggarwal",
TITLE="{Mid-Level} Networks Potential Technical Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1291,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1991,
ABSTRACT={This document proposes a set of technical services that each
Internet mid-level network can offer within the mid-level network itself
and 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{"}. It discusses the pros and cons of offering these services,
as well as areas in which mid-level networks can work together. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1291.txt"
}

@TECHREPORT{rfc1280,
AUTHOR="Editor J. Postel",
TITLE="{IAB} Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1280,
PAGES=32,
DAYS=15,
MONTH=mar,
YEAR=1992,
ABSTRACT="Discussion of the standardization process and the RFC document
series is presented first, followed by an explanation of the terms.
Sections 6.2 - 6.9 contain the lists of protocols in each stage of
standardization. Finally come pointers to references and contacts for
further information. This memo is intended to be issued quarterly;
please be sure the copy you are reading is current. Current copies may
be obtained from the Network Information Center or from the Internet
Assigned Numbers Authority (see the contact information at the end of
this memo). Do not use this edition after 31-July-92. See Section 6.1
for a description of recent changes. In the official lists in sections
6.2 - 6.9, 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.",
URL="http://www.rfc-editor.org/rfc/rfc1280.txt"
}

@TECHREPORT{rfc1285,
AUTHOR="J. D. Case",
TITLE="{FDDI} Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1285,
PAGES=46,
DAYS=15,
MONTH=jan,
YEAR=1992,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing devices which
implement the FDDI.",
URL="http://www.rfc-editor.org/rfc/rfc1285.txt"
}

@TECHREPORT{rfc1292,
AUTHOR="R. J. Lang and R. Wright",
TITLE="A Catalog of Available {X.500} Implementations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1292,
PAGES=103,
DAYS=15,
MONTH=jan,
YEAR=1992,
ABSTRACT="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(at)merit.edu) or to the
editors.",
URL="http://www.rfc-editor.org/rfc/rfc1292.txt"
}

@TECHREPORT{rfc1293,
AUTHOR="T. T. Bradley and C. M. Brown",
TITLE="Inverse Address Resolution Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1293,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1293.txt"
}

@TECHREPORT{rfc1294,
AUTHOR="T. T. Bradley and C. M. Brown and A. Malis",
TITLE="Multiprotocol Interconnect over Frame Relay",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1294,
PAGES=28,
DAYS=15,
MONTH=jan,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1294.txt"
}

@TECHREPORT{rfc1295,
AUTHOR=" {{North American Directory Forum}}",
TITLE="User Bill of Rights for entries and listings in the Public Directory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1295,
MONTH=jan,
YEAR=1992,
ABSTRACT={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). User Bill of Rights for entries and listings in the Public
Directory 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: I. The right not to be listed. II. The
right to have you or your agent informed when your entry is created.
III. The right to examine your entry. IV. The right to correct
inaccurate information in your entry. V. The right to remove specific
information from your entry. 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. VII. The right to expect
timely fulfillment of these rights.},
URL="http://www.rfc-editor.org/rfc/rfc1295.txt"
}

@TECHREPORT{rfc1296,
AUTHOR="M. Lottor",
TITLE="Internet Growth {(1981-1991)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1296,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1296.txt"
}

@TECHREPORT{rfc1297,
AUTHOR="D. B. Johnson",
TITLE={{NOC} Internal Integrated Trouble Ticket System Functional Specification
Wishlist {({"}NOC} {TT} {REQUIREMENTS{"})}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1297,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1992,
ABSTRACT={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. 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. This document explores competing uses, architectures, and
desirable features of integrated internal trouble ticket systems for
Network and other Operations Centers.},
URL="http://www.rfc-editor.org/rfc/rfc1297.txt"
}

@TECHREPORT{rfc1298,
AUTHOR="R. Wormley and S. Bostock",
TITLE="{SNMP} over {IPX}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1298,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1298.txt"
}

@TECHREPORT{rfc1300,
AUTHOR="S. Greenfield",
TITLE="Remembrances of Things Past",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1300,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1992,
ABSTRACT="A poem.",
URL="http://www.rfc-editor.org/rfc/rfc1300.txt"
}

@TECHREPORT{rfc1301,
AUTHOR="S. Armstrong and A. Freier and K. Marzullo",
TITLE="Multicast Transport Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1301,
PAGES=38,
DAYS=15,
MONTH=feb,
YEAR=1992,
ABSTRACT="This memo describes a protocol for reliable transport that
utilizes the multicast capability of applicable lower layer networking
architectures. The transport definition permits an arbitrary number of
transport providers to perform realtime collaborations without requiring
networking clients (aka, applications) to possess detailed knowledge of
the population or geographical dispersion of the participating members.
It is not network architectural specific, but does implicitly require
some form of multicasting (or broadcasting) at the data link level, as
well as some means of communicating that capability up through the
layers to the transport. Keywords: reliable transport, multicast,
broadcast, collaboration, networking.",
URL="http://www.rfc-editor.org/rfc/rfc1301.txt"
}

@TECHREPORT{rfc1302,
AUTHOR="D. Sitzler and P. W. Smith and A. N. Marine",
TITLE="Building a Network Information Services Infrastructure",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1302,
PAGES=13,
DAYS=15,
MONTH=feb,
YEAR=1992,
ABSTRACT="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: - 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. - Describe existing NIC services as an aid to Internet users and
as a model for organizations establishing new NICs.",
URL="http://www.rfc-editor.org/rfc/rfc1302.txt"
}

@TECHREPORT{rfc1303,
AUTHOR="K. McCloghrie and M. P. Rose",
TITLE="A Convention for Describing {SNMP-based} Agents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1303,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=1992,
ABSTRACT="This memo suggests a straight-forward approach towards
describing SNMP-based agents.",
URL="http://www.rfc-editor.org/rfc/rfc1303.txt"
}

@TECHREPORT{rfc1304,
EDITOR="T. F. Cox and K. Tesink",
TITLE="Definitions of Managed Objects for the {SIP} Interface Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1304,
PAGES=25,
DAYS=15,
MONTH=feb,
YEAR=1992,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing SIP (SMDS
Interface Protocol) objects.",
URL="http://www.rfc-editor.org/rfc/rfc1304.txt"
}

@TECHREPORT{rfc1305,
AUTHOR="D. L. Mills",
TITLE="Network Time Protocol (Version {3)} Specification, Implementation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1305,
PAGES=98,
DAYS=15,
MONTH=mar,
YEAR=1992,
ABSTRACT="This document describes the Network Time Protocol (NTP),
specifies its formal 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.",
URL="http://www.rfc-editor.org/rfc/rfc1305.txt"
}

@TECHREPORT{rfc1306,
AUTHOR="A. Nicholson and J. Young",
TITLE="Experiences Supporting {By-Request} {Circuit-Switched} {T3} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1306,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1992,
ABSTRACT="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. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1306.txt"
}

@TECHREPORT{rfc1307,
AUTHOR="J. Young and A. Nicholson",
TITLE="Dynamically Switched Link Control Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1307,
PAGES=13,
DAYS=15,
MONTH=mar,
YEAR=1992,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1307.txt"
}

@TECHREPORT{rfc1308,
AUTHOR="C. Weider and J. F. Reynolds",
TITLE="Executive Introduction to Directory Services Using the {X.500} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1308,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1992,
ABSTRACT="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. 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).",
URL="http://www.rfc-editor.org/rfc/rfc1308.txt"
}

@TECHREPORT{rfc1309,
AUTHOR="C. Weider and J. F. Reynolds and S. Heker",
TITLE="Technical Overview of Directory Services Using the {X.500} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1309,
PAGES=16,
DAYS=15,
MONTH=mar,
YEAR=1992,
ABSTRACT="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. 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. 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).",
URL="http://www.rfc-editor.org/rfc/rfc1309.txt"
}

@TECHREPORT{rfc1310,
AUTHOR="L. Chapin",
TITLE="The Internet Standards Process",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1310,
PAGES=23,
DAYS=15,
MONTH=mar,
YEAR=1992,
ABSTRACT={This memo documents the process currently used for the
standardization of Internet protocols and procedures. The Internet, a
loosely-organized international collaboration of autonomous,
interconnected networks, supports host-to-host communication through
voluntary adherence to open protocols and procedures defined by Internet
Standards. There are also many isolated internets, i.e., sets of
interconnected networks, that are not connected to the Internet but use
the Internet Standards. The architecture and technical specifications of
the Internet are the result of numerous research and development
activities conducted over a period of two decades, performed by the
network R\&D community, by service and equipment vendors, and by
government agencies around the world. In general, an Internet Standard
is a specification that is stable and well-understood, is technically
competent, has multiple, independent, and interoperable implementations
with operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet. The principal
set of Internet Standards is commonly known as the {"}TCP/IP protocol
suite{"}. As the Internet evolves, new protocols and services, in
particular those for Open Systems Interconnection (OSI), have been and
will be deployed in traditional TCP/IP environments, leading to an
Internet that supports multiple protocol suites. This document concerns
all protocols, procedures, and conventions used in the Internet, not
just the TCP/IP protocols. In outline, the process of creating an
Internet Standard is straightforward: a specification undergoes a period
of development and several iterations of review by the Internet
community and perhaps revision based upon experience, is adopted as a
Standard by the appropriate body (see below), and is published. In
practice, the process is somewhat more complicated, due to (1) the
number and type of possible sources for specifications; (2) the need to
prepare and revise a specification in a manner that preserves the
interests of all of the affected parties; (3) the importance of
establishing widespread community agreement on its technical content;
and (4) the difficulty of evaluating the utility of a particular
specification for the Internet community.},
URL="http://www.rfc-editor.org/rfc/rfc1310.txt"
}

@TECHREPORT{rfc1311,
AUTHOR="J. B. Postel",
TITLE="Introduction to the {STD} Notes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1311,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1992,
ABSTRACT="The STDs are a subseries of notes within the RFC series that
are the Internet standards. The intent is to identify clearly for the
Internet community those RFCs which document Internet standards.",
URL="http://www.rfc-editor.org/rfc/rfc1311.txt"
}

@TECHREPORT{rfc1312,
AUTHOR="R. T. Nelson and G. Arnold",
TITLE="Message Send Protocol 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1312,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT={The Message Send Protocol is used to send a short message to a
given user on a given terminal on a given host. Unix's write command
offers a limited form of this service through its host-local write
command. This service is also known on some hosts as {"}SEND{"}. As the
Internet grows, more and more people are using hosts that do not run
Internet protocols at all times. These hosts may be able to use a simple
protocol that can be implemented using UDP and IP. The Message Send
Protocol is one such protocol.},
URL="http://www.rfc-editor.org/rfc/rfc1312.txt"
}

@TECHREPORT{rfc1313,
AUTHOR="C. Partridge",
TITLE="Today's Programming for {KRFC} {AM} 1313 Internet Talk Radio",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1313,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT="Hi and welcome to KRFC Internet Talk Radio, your place on the
AM dial for lively talk and just-breaking news on internetworking.
Sponsored by the Internet Society, KRFC serves the San Francisco Bay
Area. For those of you outside the Bay Area, copies of program
transcripts can be anonymously FTPed from archives.krfc.com the day
after the program, or you can listen in via vat.",
URL="http://www.rfc-editor.org/rfc/rfc1313.txt"
}

@TECHREPORT{rfc1314,
AUTHOR="A. R. Katz and D. Cohen",
TITLE="A File Format for the Exchange of Images in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1314,
PAGES=23,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT={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). The standard is: ** The file format should be TIFF-B with
multi-page files supported. Images should be encoded as one TIFF strip
per page. ** 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{"}. ** 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). 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. Experimentation with this
file format specified here is encouraged.},
URL="http://www.rfc-editor.org/rfc/rfc1314.txt"
}

@TECHREPORT{rfc1315,
AUTHOR="C. M. Brown and F. Baker and C. Carvalho",
TITLE="Management Information Base for Frame Relay {DTEs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1315,
PAGES=19,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing Frame Relay.",
URL="http://www.rfc-editor.org/rfc/rfc1315.txt"
}

@TECHREPORT{rfc1316,
AUTHOR="B. Stewart",
TITLE="Definitions of Managed Objects for Character Stream Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1316,
PAGES=17,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular it defines objects for the management of
character stream devices.",
URL="http://www.rfc-editor.org/rfc/rfc1316.txt"
}

@TECHREPORT{rfc1317,
AUTHOR="B. Stewart",
TITLE="Definitions of Managed Objects for {RS-232-like} Hardware Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1317,
PAGES=17,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular, it defines objects for the management of
RS-232-like devices.",
URL="http://www.rfc-editor.org/rfc/rfc1317.txt"
}

@TECHREPORT{rfc1318,
AUTHOR="B. Stewart",
TITLE="Definitions of Managed Objects for Parallel-printer-like Hardware Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1318,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular, it defines objects for the management of
parallel-printer-like devices.",
URL="http://www.rfc-editor.org/rfc/rfc1318.txt"
}

@TECHREPORT{rfc1319,
AUTHOR="B. Kaliski",
TITLE="The {MD2} {Message-Digest} Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1319,
PAGES=17,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT="This document describes the MD2 message-digest algorithm. The
algorithm takes as input a 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 MD2 algorithm is
intended for digital signature applications, where a large file must be
``compressed'' in a secure manner before being signed with a private
(secret) key under a public-key cryptosystem such as RSA. License to use
MD2 is granted for non-commerical Internet Privacy-Enhanced Mail.",
URL="http://www.rfc-editor.org/rfc/rfc1319.txt"
}

@TECHREPORT{rfc1320,
AUTHOR="R. Rivest",
TITLE="The {MD4} {Message-Digest} Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1320,
PAGES=20,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT={This document describes the MD4 message-digest algorithm. The
algorithm takes as input a 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
intended for digital signature applications, where a large file must be
{"}compressed{"} in a secure manner before being encrypted with a private
(secret) key under a public-key cryptosystem such as RSA. The MD4
algorithm is designed to be quite fast on 32-bit machines. In addition,
the MD4 algorithm does not require any large substitution tables; the
algorithm can be coded quite compactly.},
URL="http://www.rfc-editor.org/rfc/rfc1320.txt"
}

@TECHREPORT{rfc1321,
AUTHOR="R. Rivest",
TITLE="The {MD5} {Message-Digest} Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1321,
PAGES=21,
DAYS=15,
MONTH=apr,
YEAR=1992,
ABSTRACT="This document describes the MD5 message-digest algorithm. The
algorithm takes as input a 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 MD5 algorithm is
intended for digital signature applications, where a large file must be
``compressed'' in a secure manner before being encrypted with a private
(secret) key under a public-key cryptosystem such as RSA. The MD5
algorithm is designed to be quite fast on 32-bit machines. In addition,
the MD5 algorithm does not require any large substitution tables; the
algorithm can be coded quite compactly. The MD5 algorithm is an
extension of the MD4 message-digest algorithm. MD5 is slightly slower
than MD4, but is more ``conservative'' in design. MD5 was designed
because it was felt that MD4 was perhaps being adopted for use more
quickly than justified by the existing critical review; because MD4 was
designed to be exceptionally fast, it is ``at the edge'' in terms of
risking successful cryptanalytic attack. MD5 backs off a bit, giving up
a little in speed for a much greater likelihood of ultimate security. It
incorporates some suggestions made by various reviewers, and contains
additional optimizations. The MD5 algorithm is being placed in the
public domain for review and possible adoption as a standard.",
URL="http://www.rfc-editor.org/rfc/rfc1321.txt"
}

@TECHREPORT{rfc1322,
AUTHOR="D. Estrin and Y. Rekhter and S. Hotz",
TITLE="A Unified Approach to {Inter-Domain} Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1322,
PAGES=38,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1322.txt"
}

@TECHREPORT{rfc1323,
AUTHOR="V. Jacobson and R. Braden and D. Borman",
TITLE="{TCP} Extensions for High Performance",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1323,
PAGES=37,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1323.txt"
}

@TECHREPORT{rfc1324,
AUTHOR="D. P. Reed",
TITLE="A Discussion on Computer Network Conferencing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1324,
PAGES=11,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1324.txt"
}

@TECHREPORT{rfc1325,
AUTHOR="G. Malkin and A. N. Marine",
TITLE={{FYI} on Questions and Answers Answers to Commonly asked {"}New Internet
User{"} Questions},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1325,
PAGES=42,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1325.txt"
}

@TECHREPORT{rfc1326,
AUTHOR="P. Tsuchiya",
TITLE="Mutual Encapsulation Considered Dangerous",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1326,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="This memo describes a packet explosion problem that can occur
with mutual encapsulation of protocols (A encapsulates B and B
encapsulates A).",
URL="http://www.rfc-editor.org/rfc/rfc1326.txt"
}

@TECHREPORT{rfc1327,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="Mapping between {X.400(1988)} / {ISO} 10021 and {RFC} 822",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1327,
PAGES=113,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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 protocol or 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1327.txt"
}

@TECHREPORT{rfc1328,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="{X.400} 1988 to 1984 downgrading",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1328,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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. This specification is not tutorial. COSINE
Study 8.2 by J.A.I. Craigie gives a useful overview.",
URL="http://www.rfc-editor.org/rfc/rfc1328.txt"
}

@TECHREPORT{rfc1329,
AUTHOR="P. Kuehn",
TITLE="Thoughts on Address Resolution for Dual {MAC} {FDDI} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1329,
PAGES=28,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1329.txt"
}

@TECHREPORT{rfc1330,
AUTHOR=" ",
TITLE="Recommendations for the Phase I Deployment of {OSI} Directory Services
{(X.500)} and {OSI} Message Handling Services {(X.400)} within the {ESNET}
Community",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1330,
PAGES=87,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="The Energy Sciences Network (ESnet) is a nation-wide computer
data communications network managed and funded by the United States
Department of Energy, Office of Energy Research (U.S. DOE/OER), for the
purpose of supporting multiple program, open scientific research. ESnet
is intended to facilitate remote access to major Energy Research (ER)
scientific facilities, provide needed information dissemination among
scientific collaborators throughout all ER programs, and provide
widespread access to existing ER supercomputer facilities. Coordination
of ER-wide network-related technical activities over the ESnet backbone
is achieved through the ESnet Site Coordinating Committee (ESCC). This
committee is comprised of one technical contact person from each
backbone site, as well as some members of the ESnet management and
networking staff. As the need for new levels of ESnet services arise,
the ESCC typically creates task forces to investigate and research
issues relating to these new services. Each task force usually results
in a whitepaper which makes recommendations to the ESnet community on
how these services should be deployed to meet the mission of DOE/OER.
This RFC is a near verbatim copy of the whitepaper produced by the ESnet
Site Coordinating Committee's X.500/X.400 Task Force.",
URL="http://www.rfc-editor.org/rfc/rfc1330.txt"
}

@TECHREPORT{rfc1331,
AUTHOR="W. Simpson",
TITLE="The {Point-to-Point} Protocol {(PPP)} for the Transmission of
Multi-protocol Datagrams over {Point-to-Point} Links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1331,
PAGES=66,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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: 1. A method for encapsulating
datagrams over serial links. 2. A Link Control Protocol (LCP) for
establishing, configuring, and testing the data-link connection. 3. A
family of Network Control Protocols (NCPs) for establishing and
configuring different network-layer protocols. 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. 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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1331.txt"
}

@TECHREPORT{rfc1332,
AUTHOR="G. McGregor",
TITLE="The {PPP} Internet Protocol Control Protocol {(IPCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1332,
PAGES=12,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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. This document defines
the NCP for establishing and configuring the Internet Protocol over PPP,
and a method to negotiate and use Van Jacobson TCP/IP header compression
with PPP. This RFC is a product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF).",
URL="http://www.rfc-editor.org/rfc/rfc1332.txt"
}

@TECHREPORT{rfc1333,
AUTHOR="W. Simpson",
TITLE="{PPP} Link Quality Monitoring",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1333,
PAGES=15,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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. This document defines a protocol for
generating Link-Quality-Reports. 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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1333.txt"
}

@TECHREPORT{rfc1334,
AUTHOR="B. Lloyd and W. Simpson",
TITLE="{PPP} Authentication Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1334,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT="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.
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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1334.txt"
}

@TECHREPORT{rfc1335,
AUTHOR="Z. Wang and Jon Crowcroft",
TITLE="A {Two-Tier} Address Structure for the Internet: A Solution to the Problem
of Address Space Exhaustion",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1335,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1335.txt"
}

@TECHREPORT{rfc1336,
AUTHOR="G. Malkin",
TITLE="Who's Who in the Internet: Biographies of {IAB,} {IESG} and {IRSG} Members",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1336,
PAGES=33,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="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 the Internet Research Steering Group (IRSG) of the Internet Research
Task Force (IRTF).",
URL="http://www.rfc-editor.org/rfc/rfc1336.txt"
}

@TECHREPORT{rfc1337,
AUTHOR="R. Braden",
TITLE="{TIME-WAIT} Assassination Hazards in {TCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1337,
PAGES=11,
DAYS=15,
MONTH=may,
YEAR=1992,
ABSTRACT="This note describes some theoretically-possible failure modes
for TCP connections and discusses possible remedies. In particular, one
very simple fix is identified.",
URL="http://www.rfc-editor.org/rfc/rfc1337.txt"
}

@TECHREPORT{rfc1338,
AUTHOR="V. Fuller and T. Li and J. Yu and K. Varadhan",
TITLE="Supernetting: an Address Assignment and Aggregation Strategy",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1338,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1338.txt"
}

@TECHREPORT{rfc1339,
AUTHOR="S. Dorner and Paul  Resnick",
TITLE="Remote Mail Checking Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1339,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1339.txt"
}

@TECHREPORT{rfc1340,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Assigned Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1340,
PAGES=139,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT={This Network Working Group Request for Comments documents the
currently assigned values from several series of numbers used in network
protocol implementations. This RFC will be updated periodically, and in
any case current information can be obtained from the Internet Assigned
Numbers Authority (IANA). If you are developing a protocol or
application that will require the use of a link, socket, port, protocol,
etc., please contact the IANA to receive a number assignment. Joyce K.
Reynolds Internet Assigned Numbers Authority USC - Information Sciences
Institute 4676 Admiralty Way Marina del Rey, California 90292-6695
Phone: (310) 822-1511 Electronic mail: IANA(at)ISI.EDU Most of the
protocols mentioned here are documented in the RFC series of notes. Some
of the items listed are undocumented. Further information on protocols
can be found in the memo {"}IAB Official Protocol Standards{"}. In the
entries below, the name and mailbox of the responsible individual is
indicated. The bracketed entry, e.g., [nn, iii], at the right hand
margin of the page indicates a reference for the listed protocol, where
the number ({"}nn{"}) cites the document and the letters ({"}iii{"}) cites
the
person. Whenever possible, the letters are a NIC Ident as used in the
WhoIs (NICNAME) service.},
URL="http://www.rfc-editor.org/rfc/rfc1340.txt"
}

@TECHREPORT{rfc1341,
AUTHOR="N. Borenstein and N. Freed",
TITLE="{MIME} (Multipurpose Internet Mail Extensions): Mechanisms for Specifying
and Describing the Format of Internet Message Bodies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1341,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT="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. 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. 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 [RFC1342].",
URL="http://www.rfc-editor.org/rfc/rfc1341.txt"
}

@TECHREPORT{rfc1342,
AUTHOR="K. Moore",
TITLE="Representation of {Non-ASCII} Text in Internet Message Headers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1342,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT={This memo describes an extension to the message format defined
in RFC 1341 (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.},
URL="http://www.rfc-editor.org/rfc/rfc1342.txt"
}

@TECHREPORT{rfc1343,
AUTHOR="N. Borenstein",
TITLE="A User Agent Configuration Mechanism for Multimedia Mail Format Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1343,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT="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 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.",
URL="http://www.rfc-editor.org/rfc/rfc1343.txt"
}

@TECHREPORT{rfc1344,
AUTHOR="N. Borenstein",
TITLE="Implications of {MIME} for Internet Mail Gateways",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1344,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1344.txt"
}

@TECHREPORT{rfc1345,
AUTHOR="K. Simonsen",
TITLE="Character Mnemonics and Character Sets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1345,
PAGES=103,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT="This memo lists a selection of characters and their presence
in some coded character sets. To facilitate the coded character set
tabulations an unambiguous mnemonic for each character is used, and a
format for tabulating the coded character sets is defined. The coded
character sets are given names for easy reference. A family of coded
character sets called the mnemonic character sets and conversion between
these coded character set without information loss is defined. The
character set names are registered with the Internet Assigned Numbers
Authority (IANA). Additional character sets not described in this memo
should be registered with the IANA. This memo may be updated
periodically, or additional specifications may be published, to reflect
other coded character sets. Please send any comments including comments
about the accuracy of the tables to the author, Keld Simonsen
<Keld.Simonsen(at)dkuug.dk>.",
URL="http://www.rfc-editor.org/rfc/rfc1345.txt"
}

@TECHREPORT{rfc1346,
AUTHOR="P. Jones",
TITLE="Resource Allocation, Control, and Accounting for the Use of Network
Resources",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1346,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT="This paper gives reasons for wanting better sharing mechanisms
for networks. It concludes that the challenge of sharing network
resources (and for example intercontinental link resources) between
groups of users is neither well understood, nor well catered for in
terms of tools for those responsible for managing the services. The
situation is compared with other fields, both inside and outside IT, and
examples are cited. Recommendations for further work are made. The
purpose of this RFC is to focus discussion on particular challenges in
large service networks in general, and the International IP Internet in
particular. No solution discussed in this document is intended as a
standard. Rather, it is hoped that a general consensus will emerge as to
the appropriate solutions, leading eventually to the adoption of
standards.",
URL="http://www.rfc-editor.org/rfc/rfc1346.txt"
}

@TECHREPORT{rfc1347,
AUTHOR="R. Callon",
TITLE="{TCP} and {UDP} with Bigger Addresses {(TUBA),} A Simple Proposal for
Internet Addressing and Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1347,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1992,
ABSTRACT={This paper describes a simple proposal which provides a
long-term solution to Internet addressing, routing, and scaling. This
involves a gradual migration from the current Internet Suite (which is
based on Internet applications, running over TCP or UDP, running over
IP) to an updated suite (based on the same Internet applications,
running over TCP or UDP, running over CLNP). This approach is known as
{"}TUBA{"} (TCP \& UDP with Bigger Addresses). This paper describes a
proposal for how transition may be accomplished. Description of the
manner in which use of CLNP, NSAP addresses, and related
network/Internet layer protocols (ES-IS, IS-IS, and IDRP) allow scaling
to a very large ubiquitous worldwide Internet is outside of the scope of
this paper.},
URL="http://www.rfc-editor.org/rfc/rfc1347.txt"
}

@TECHREPORT{rfc1348,
AUTHOR="B. Manning",
TITLE="{DNS} {NSAP} {RRs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1348,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT="This RFC defines the format of two new Resource Records (RRs)
for the Domain Name System (DNS), and reserves corresponding DNS type
mnemonic and numerical codes. This format may be used with the any
proposal that has variable length addresses, but is targeted for CLNP
use. This memo assumes that the reader is familiar with the DNS.",
URL="http://www.rfc-editor.org/rfc/rfc1348.txt"
}

@TECHREPORT{rfc1349,
AUTHOR="P. Almquist",
TITLE="Type of Service in the Internet Protocol Suite",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1349,
PAGES=28,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT="This memo changes and clarifies some aspects of the semantics
of the Type of Service octet in the Internet Protocol (IP) header. The
handling of IP Type of Service by both hosts and routers is specified in
some detail. This memo defines a new TOS value for requesting that the
network minimize the monetary cost of transmitting a datagram. A number
of additional new TOS values are reserved for future experimentation and
standardization. The ability to request that transmission be optimized
along multiple axes (previously accomplished by setting multiple TOS
bits simultaneously) is removed. Thus, for example, a single datagram
can no longer request that the network simultaneously minimize delay and
maximize throughput. In addition, there is a minor conflict between the
Host Requirements (RFC-1122 and RFC-1123) and a number of other
standards concerning the sizes of the fields in the Type of Service
octet. This memo resolves that conflict.",
URL="http://www.rfc-editor.org/rfc/rfc1349.txt"
}

@TECHREPORT{rfc1350,
AUTHOR="K. Sollins",
TITLE="The {TFTP} Protocol (Revision {2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1350,
PAGES=11,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT="TFTP is a very simple protocol used to transfer files. It is
from this that its name comes, Trivial File Transfer Protocol or TFTP.
Each nonterminal packet is acknowledged separately. This document
describes the protocol and its types of packets. The document also
explains the reasons behind some of the design decisions.",
URL="http://www.rfc-editor.org/rfc/rfc1350.txt"
}

@TECHREPORT{rfc1351,
AUTHOR="J. R. Davin and J. Galvin and K. McCloghrie",
TITLE="{SNMP} Administrative Model",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1351,
PAGES=35,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT="This memo presents an elaboration of the SNMP administrative
model set forth in RFC XXX. This model provides a unified conceptual
basis for administering SNMP protocol entities to support authentication
and integrity, privacy, access control, and the cooperation of multiple
protocol entities.",
URL="http://www.rfc-editor.org/rfc/rfc1351.txt"
}

@TECHREPORT{rfc1352,
AUTHOR="J. Galvin and K. McCloghrie and J. R. Davin",
TITLE="{SNMP} Security Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1352,
PAGES=41,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT="The Simple Network Management Protocol (SNMP) specification
allows for the protection of network management operations by a variety
of security protocols. The SNMP administrative model described in RFC
XXX provides a framework for securing SNMP network management. In the
context of that framework, this memo defines protocols to support the
following three security services: data integrity, data origin
authentication, and data confidentiality. Please send comments to the
SNMP Security Developers mailing list (snmp-sec-dev(at)tis.com).",
URL="http://www.rfc-editor.org/rfc/rfc1352.txt"
}

@TECHREPORT{rfc1353,
AUTHOR="K. McCloghrie and J. R. Davin and J. Galvin",
TITLE="Definitions of Managed Objects for Administration of {SNMP} Parties",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1353,
PAGES=26,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it describes a representation of the SNMP
parties defined in RFC XXX as objects defined according to the Internet
Standard SMI. These definitions are consistent with the SNMP Security
protocols set forth in RFC XXX.",
URL="http://www.rfc-editor.org/rfc/rfc1353.txt"
}

@TECHREPORT{rfc1354,
AUTHOR="F. Baker",
TITLE="{IP} Forwarding Table {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1354,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing routes in the
IP Internet. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1354.txt"
}

@TECHREPORT{rfc1355,
AUTHOR="J. Curran and A. N. Marine",
TITLE="Privacy and Accuracy Issues in Network Information Center Databases",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1355,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1355.txt"
}

@TECHREPORT{rfc1356,
AUTHOR="A. Malis and D. Robinson and R. Ullmann",
TITLE="Multiprotocol Interconnect on {X.25} and {ISDN} in the Packet Mode",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1356,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=1992,
ABSTRACT={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{"}. 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. 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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1356.txt"
}

@TECHREPORT{rfc1357,
AUTHOR="D. Cohen",
TITLE="A Format for E-mailing Bibliographic Records",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1357,
PAGES=13,
DAYS=15,
MONTH=jul,
YEAR=1992,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1357.txt"
}

@TECHREPORT{rfc1358,
AUTHOR="L. Chapin",
TITLE="Charter of the Internet Architecture Board {(IAB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1358,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1992,
ABSTRACT={The Internet Architecture Board (IAB) shall be constituted and
shall operate as a technical advisory group of the Internet Society. Its
responsibilities shall include: (1) Expert and experienced oversight of
the architecture of the worldwide multiprotocol Internet. (2) The
editorial management and publication of the Request for Comments (RFC)
document series, which constitutes the archival publication series for
Internet Standards and related contributions by the Internet research
and engineering community. (3) The development, review, and approval of
Internet Standards, according to a well-defined and documented set of
{"}Procedures for Internet Standardization{"}. Internet Standards shall be
published in the form of specifications as part of the RFC series. (4)
The provision of advice and guidance to the Board of Trustees and
Officers of the Internet Society concerning technical, architectural,
procedural, and (where appropriate) policy matters pertaining to the
Internet and its enabling technologies. (5) Representation of the
interests of the Internet Society in liaison relationships with other
organizations.},
URL="http://www.rfc-editor.org/rfc/rfc1358.txt"
}

@TECHREPORT{rfc1359,
AUTHOR="Acm Siguccs",
TITLE="Connecting to the Internet - What Connecting Institutions Should Anticipate",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1359,
PAGES=25,
DAYS=15,
MONTH=aug,
YEAR=1992,
ABSTRACT="This FYI RFC outlines the major issues an institution should
consider in the decision and implementation of a campus connection to
the Internet. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1359.txt"
}

@TECHREPORT{rfc1361,
AUTHOR="D. L. Mills",
TITLE="Simple Network Time Protocol {(SNTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1361,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1992,
ABSTRACT="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. This
memorandum does not obsolete or update any RFC. A working knowledge of
RFC-1305 is not required for an implementation of SNTP.",
URL="http://www.rfc-editor.org/rfc/rfc1361.txt"
}

@TECHREPORT{rfc1362,
AUTHOR="M. Allen",
TITLE="Novell {IPX} over Various {WAN} Media {(IPXWAN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1362,
PAGES=13,
DAYS=15,
MONTH=sep,
YEAR=1992,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1362.txt"
}

@TECHREPORT{rfc1363,
AUTHOR="C. Partridge",
TITLE="A Proposed Flow Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1363,
PAGES=20,
DAYS=15,
MONTH=sep,
YEAR=1992,
ABSTRACT={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. 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).},
URL="http://www.rfc-editor.org/rfc/rfc1363.txt"
}

@TECHREPORT{rfc1364,
AUTHOR="K. Varadhan",
TITLE="{BGP} {OSPF} Interaction",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1364,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1364.txt"
}

@TECHREPORT{rfc1365,
AUTHOR="K. Siyan",
TITLE="An {IP} Address Extension Proposal",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1365,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1992,
ABSTRACT="This RFC suggests an extension to the IP protocol to solve the
shortage of IP address problem, and requests discussion and suggestions
for improvements.",
URL="http://www.rfc-editor.org/rfc/rfc1365.txt"
}

@TECHREPORT{rfc1366,
AUTHOR="E. Gerich",
TITLE="Guidelines for Management of {IP} Address Space",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1366,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1366.txt"
}

@TECHREPORT{rfc1367,
AUTHOR="C. Topolcic",
TITLE="Schedule for {IP} Address Space Management Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1367,
PAGES=3,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT="This memo suggests a schedule for the implementation of the IP
network number allocation plan described in RFC 1366. This schedule is
meant to support the implementation and deployment of an address
aggregation mechanism for the Internet by proposing an achievable target
for which we can all aim. The timely deployment of that aggregation
mechanism and the IP addressing plan will help the the size of the
Internet router forwarding tables and management of the IP address
space. By doing so, it will help the current Internet addressing and
routing technology operate during the interim period until the next
generation technology is deployed. This interim solution in no way
constrains the selection of the next generation addressing and routing
technology. This draft schedule was put together by the FNC Engineering
and Planning Group (FEPG) based on the IP addressing plan BOF of the
July 1992 IETF meeting, as well as discussions with a number (though, of
course, not all) of knowledgeable and interested parties, including the
IANA and IR. This draft schedule assumes that the address aggregation
mechanism will be available in the Internet by mid-1993. The activities
described in this schedule are the precursors to that deployment, and
will promote the efficient operation of that mechanism. We feel that our
assumptions are realistic and that this schedule can be met. We
encourage its open discussion as we move toward community consensus.
Please send comments to topolcic(at)nri.reston.va.us, or to the mailing
list ipalloc(at)nri.reston.va.us. To be added to this mailing list, send a
request to ipalloc-request(at)nri.reston.va.us. Note that the references
below to an addressing plan and to criteria for regional address
registries refer to RFC 1366.",
URL="http://www.rfc-editor.org/rfc/rfc1367.txt"
}

@TECHREPORT{rfc1368,
AUTHOR="D. McMaster and K. McCloghrie",
TITLE="Definition of Managed Objects for {IEEE} {802.3} Repeater Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1368,
PAGES=40,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT={This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing IEEE 802.3 10
Mb/second baseband repeaters, sometimes referred to as {"}hubs.{"}},
URL="http://www.rfc-editor.org/rfc/rfc1368.txt"
}

@TECHREPORT{rfc1369,
AUTHOR="F. Kastenholz",
TITLE="Implementation Notes and Experience for the Internet Ethernet {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1369,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT="The Ethernet MIB Working group has been tasked with the
following two work items: 1) Develop a document explaining the rationale
for assigning MANDATORY status to MIB variables which are optional in
the relevant IEEE 802.3 specification (the technical basis for the
Internet Ethernet MIB). This shall not be a standards-track document.
(2) Develop an implementation report on the Ethernet MIB. This report
shall cover MIB variables which are implemented in both Ethernet
interface chips, and in software (i.e., drivers), and discuss the issues
pertaining to both. This report shall also summarize field experience
with the MIB variables, especially concentrating on those variables
which are in dispute. This document shall not be a standards-track
document. While the Ethernet MIB is progressing through the
standardization process, this document shall be periodically updated to
reflect the latest implementation and operational experience.",
URL="http://www.rfc-editor.org/rfc/rfc1369.txt"
}

@TECHREPORT{rfc1370,
AUTHOR="Internet Activities Board and L. Chapin",
TITLE="Applicability Statement for {OSPF}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1370,
PAGES=2,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT="Users and vendors have expressed a strong need for IP routers
from different vendors that can interoperate using a common Interior
Gateway Protocol (IGP). There is therefore an urgent requirement for a
high-functionality non-proprietary 'open' IGP that will be ubiquitously
available from all IP router vendors. The Open Shortest Path First
(OSPF) routing protocol was developed by the IETF to fill this need.
This Applicability Statement specifies the circumstances under which
OSPF must be implemented by router vendors. The history of OSPF
development and the reasoning behind this Applicability Statement will
be found in RFC XXX. This Applicability Statement places a requirement
on vendors claiming conformance to this standard, in order to assure
that users will have the option of deploying OSPF when they need a
multivendor, interoperable IGP in their environment. Users are of course
free to use whatever routing protocol best meets their requirements.",
URL="http://www.rfc-editor.org/rfc/rfc1370.txt"
}

@TECHREPORT{rfc1371,
AUTHOR="P. Gross",
TITLE="Choosing a Common {IGP} for the {IP} Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1371,
PAGES=9,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT={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. 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. Finally, a specific IGP is
recommended as the {"}common IGP{"} for IP portions of the Internet -- the
Open Shortest Path First (OSPF) routing protocol. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1371.txt"
}

@TECHREPORT{rfc1372,
AUTHOR="C. Hedrick and D. Borman",
TITLE="Telnet Remote Flow Control Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1372,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT="This document specifies an extended version of the Telnet
Remote Flow Control Option, RFC 1080, with the addition of the
RESTART-ANY and RESTART-XON suboptions.",
URL="http://www.rfc-editor.org/rfc/rfc1372.txt"
}

@TECHREPORT{rfc1373,
AUTHOR="T. Tignor",
TITLE="Portable {DUAs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1373,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT={This document comes in two parts. The first part is for
regular people who wish to set up their own DUAs (Directory User
Interfaces) to access the Directory. It includes some brief notes on the
operation of the DUAs and instructions for their creation and
installation. The instructions are given in an easy-to-follow, step-
by-step format. It is fully expected that the user will be able to
perform the necessary operations as he reads through the instructions
for the first time and have a working DUA when he finishes. The second
part is for ISODE-maintainers wishing to provide portable DUAs to users.
This part gives instructions in a similar but longer, step-by-step
format. It is fully expected that the maintainer will be able to perform
the necessary operations as he reads through the instructions for the
first time and have a working DUA package/supporting service when he
finishes. The document currently has four sub-parts for each larger
part. The sub-parts detail the following DUAs: WHOIS, {"}de,{"} dixie's
{"}ud{"}
and ISODE's {"}doog.{"} It is intended that additional sub-parts will be
added to the document as new, portable DUA packages are designed. Where
pertinent, the document assumes ISODE 8.0 is being used. 1. Instructions
for DUA-Users WHOIS A WHOIS interface to X.500 may be available on any
ISODE-resident machine which also runs a DSA (Directory System Agent.)
Check with your local, ISODE-maintainer. If the service is available,
users can access the Directory with the following command: whois -h
<hostname> <name in UFN format>},
URL="http://www.rfc-editor.org/rfc/rfc1373.txt"
}

@TECHREPORT{rfc1374,
AUTHOR="J. Renwick and A. Nicholson",
TITLE="{IP} and {ARP} on {HIPPI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1374,
PAGES=43,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1374.txt"
}

@TECHREPORT{rfc1375,
AUTHOR="P. Robinson",
TITLE="Suggestion for New Classes of {IP} Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1375,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1992,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1375.txt"
}

@TECHREPORT{rfc1376,
AUTHOR="S. Senum",
TITLE="The {PPP} {DECnet} Phase {IV} Control Protocol {(DNCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1376,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=1992,
ABSTRACT="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. 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.).",
URL="http://www.rfc-editor.org/rfc/rfc1376.txt"
}

@TECHREPORT{rfc1377,
AUTHOR="D. Katz",
TITLE="The {PPP} {OSI} Network Layer Control Protocol {(OSINLCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1377,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1992,
ABSTRACT="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. This document defines
the NCP for establishing and configuring OSI Network Layer Protocols.
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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1377.txt"
}

@TECHREPORT{rfc1378,
AUTHOR="B. Parker",
TITLE="The {PPP} {AppleTalk} Control Protocol {(ATCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1378,
PAGES=16,
DAYS=15,
MONTH=nov,
YEAR=1992,
ABSTRACT="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. This document defines
the NCP for establishing and configuring the AppleTalk Protocol over
PPP. 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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1378.txt"
}

@TECHREPORT{rfc1379,
AUTHOR="R. Braden",
TITLE="Extending {TCP} for Transactions {--} Concepts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1379,
PAGES=38,
DAYS=15,
MONTH=nov,
YEAR=1992,
ABSTRACT="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. This work was supported in part by the National
Science Foundation under Grant Number NCR-8922231.",
URL="http://www.rfc-editor.org/rfc/rfc1379.txt"
}

@TECHREPORT{rfc1380,
AUTHOR="P. Gross and P. Almquist",
TITLE="{IESG} Deliberations on Routing and Addressing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1380,
PAGES=22,
DAYS=15,
MONTH=nov,
YEAR=1992,
ABSTRACT="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). 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.",
URL="http://www.rfc-editor.org/rfc/rfc1380.txt"
}

@TECHREPORT{rfc1381,
AUTHOR="D. Throop and F. Baker",
TITLE="{SNMP} {MIB} Extension for {X.25} {LAPB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1381,
PAGES=33,
DAYS=15,
MONTH=nov,
YEAR=1992,
ABSTRACT={This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the 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.},
URL="http://www.rfc-editor.org/rfc/rfc1381.txt"
}

@TECHREPORT{rfc1382,
EDITOR="D. Throop",
TITLE="{SNMP} {MIB} Extension for the {X.25} Packet Layer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1382,
PAGES=69,
DAYS=15,
MONTH=nov,
YEAR=1992,
ABSTRACT={This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the 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.},
URL="http://www.rfc-editor.org/rfc/rfc1382.txt"
}

@TECHREPORT{rfc1383,
AUTHOR="C. Huitema",
TITLE="An Experiment in {DNS} Based {IP} Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1383,
PAGES=14,
DAYS=15,
MONTH=dec,
YEAR=1992,
ABSTRACT={The current proposal presents a scheme that allows for simple
routing. It is complementary with the classic {"}hierarchical routing{"}
approach, but provides an easy to implement and low cost solution for
{"}multi-homed{"} domains. The solution is a generalization of the {"}MX
record{"} scheme currently used for mail routing.},
URL="http://www.rfc-editor.org/rfc/rfc1383.txt"
}

@TECHREPORT{rfc1385,
AUTHOR="Z. Wang",
TITLE="{EIP:} The Extended Internet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1385,
PAGES=17,
DAYS=15,
MONTH=nov,
YEAR=1992,
ABSTRACT={The Extended Internet Protocol (EIP) provides a framework for
solving the problem of address space exhaustion with a new addressing
and routing scheme, yet maintaining maximum backward compatibility with
current IP. EIP can substantially reduce the amount of modifications
needed to the current Internet systems and greatly ease the difficulties
of transition. This is an {"}idea{"} paper and discussion is strongly
encouraged on Big-Internet(at)munnari.oz.au.},
URL="http://www.rfc-editor.org/rfc/rfc1385.txt"
}

@TECHREPORT{rfc1386,
AUTHOR="A. Cooper and J. B. Postel",
TITLE="The {US} Domain",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1386,
PAGES=31,
DAYS=15,
MONTH=dec,
YEAR=1992,
ABSTRACT={1.1 The Internet Domain Name System The Domain Name System
(DNS) provides for the translation between host names and addresses.
Within the Internet, this means translating from a name such as
{"}venera.isi.edu{"}, to an IP address such as {"}128.9.0.32{"}. The DNS is
a
set of protocols and databases. The protocols define the syntax and
semantics for a query language to ask questions about information
located by DNS-style names. The databases are distributed and
replicated. There is no dependence on a single central server, and each
part of the database is provided in at least two servers. The assignment
of the 32-bit IP addresses is a separate activity. IP addresses are
assigned by the Network Information Center (Hostmaster(at)NIC.DDN.MIL). In
addition to translating names to addresses for hosts that are on the
Internet, the DNS provides for registering DNS-style names for other
hosts reachable (via electronic mail) through gateways or mail relays.
The records for such name registration point to an Internet host (one
with an IP address) that acts as a mail forwarder for the registered
host. For example, the host {"}bah.rochester.ny.us{"} is registered in the
DNS with a pointer to the mail relay {"}relay1.uu.net{"}. This type of
pointer is called an MX record. This gives electronic mail users a
uniform mail addressing syntax and avoids making users aware of the
underlying network boundaries. The reason for the development of the
domain system was growth in the Internet. The host name to address
mappings were maintained by the Network Information Center (NIC) in a
single file, called HOSTS.TXT, which was FTPed by all the hosts on the
Internet. The network population was changing in character. The
timeshared hosts that made up the original ARPANET were being replaced
with local networks of workstations. Local organizations were
administering their own names and addresses, but had to wait for the NIC
to make changes in HOSTS.TXT to make the changes visible to the Internet
at large. Organizations also wanted some local structure on the name
space. The applications on the Internet were getting more sophisticated
and creating a need for general purpose name service. The idea of a
hierarchical name space, with the hierarchy roughly corresponding to
organizational structure, and names using {"}.{"} as the character to mark
the boundary between hierarcy levels. A design using a distributed
database and generalized resources was implemented. The domain system
provides standard formats for resource data,},
URL="http://www.rfc-editor.org/rfc/rfc1386.txt"
}

@TECHREPORT{rfc1384,
AUTHOR="P. Barker and S. E. Hardcastle-Kille",
TITLE="Naming Guidelines for Directory Pilots",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1384,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="Deployment of a Directory will benefit from following certain
guidelines. This document defines a number of naming guidelines.
Alignment to these guidelines is recommended for directory pilots.",
URL="http://www.rfc-editor.org/rfc/rfc1384.txt"
}

@TECHREPORT{rfc1387,
AUTHOR="G. Malkin",
TITLE="{RIP} Version 2 Protocol Analysis",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1387,
PAGES=3,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="As required by Routing Protocol Criteria (RFC 1264), this
report documents the key features of the RIP-2 protocol and the current
implementation experience.",
URL="http://www.rfc-editor.org/rfc/rfc1387.txt"
}

@TECHREPORT{rfc1388,
AUTHOR="G. Malkin",
TITLE="{RIP} Version 2 Carrying Additional Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1388,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This document specifies an extension of the Routing
Information Protocol (RIP), as defined in RFC XXX, 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.",
URL="http://www.rfc-editor.org/rfc/rfc1388.txt"
}

@TECHREPORT{rfc1389,
AUTHOR="G. Malkin and F. Baker",
TITLE="{RIP} Version 2 {MIB} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1389,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing RIP Version 2.",
URL="http://www.rfc-editor.org/rfc/rfc1389.txt"
}

@TECHREPORT{rfc1390,
AUTHOR="D. Katz",
TITLE="Transmission of {IP} and {ARP} over {FDDI} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1390,
PAGES=11,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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. This
RFC is the product of the IP over FDDI Working Group of the Internet
Engineering Task Force (IETF).",
URL="http://www.rfc-editor.org/rfc/rfc1390.txt"
}

@TECHREPORT{rfc1391,
AUTHOR="G. Malkin",
TITLE="The Tao of the {IETF:} A Guide for New Attendees of the Internet
Engineering Task Force",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1391,
PAGES=19,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1391.txt"
}

@TECHREPORT{rfc1392,
AUTHOR="G. Malkin and T. LaQuey Parker",
TITLE="Internet Users' Glossary",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1392,
PAGES=53,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1392.txt"
}

@TECHREPORT{rfc1393,
AUTHOR="G. Malkin",
TITLE="Traceroute Using an {IP} Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1393,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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.
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.",
URL="http://www.rfc-editor.org/rfc/rfc1393.txt"
}

@TECHREPORT{rfc1394,
AUTHOR="P. Robinson",
TITLE="Relationship of Telex Answerback Codes to Internet Domains",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1394,
PAGES=15,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1394.txt"
}

@TECHREPORT{rfc1395,
AUTHOR="J. F. Reynolds",
TITLE="{BOOTP} Vendor Information Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1395,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This RFC is a slight revision and extension of RFC-1048 by
Philip Prindeville, who should be credited with the original work in
this memo. This memo will be updated as additional tags are are defined.
This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain
Name, Tag 16 for Swap Server and Tag 17 for Root Path. As workstations
and personal computers proliferate on the Internet, the administrative
complexity of maintaining a network is increased by an order of
magnitude. The assignment of local network resources to each client
represents one such difficulty. In most environments, delegating such
responsibility to the user is not plausible and, indeed, the solution is
to define the resources in uniform terms, and to automate their
assignment. The basic Bootstrap Protocol (RFC-951) dealt with the issue
of assigning an internet address to a client, as well as a few other
resources. The protocol included provisions for vendor-defined resource
information. This memo defines a (potentially) vendor-independent
interpretation of this resource information.",
URL="http://www.rfc-editor.org/rfc/rfc1395.txt"
}

@TECHREPORT{rfc1396,
AUTHOR="S. D. Crocker",
TITLE="The Process for Organization of Internet Standards Working Group {(POISED)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1396,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1396.txt"
}

@TECHREPORT{rfc1397,
AUTHOR="D. Haskin",
TITLE="Default Route Advertisement In {BGP2} and {BGP3} Version of The Border
Gateway Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1397,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This document specifies the recommendation of the BGP Working
Group on default route advertisement support in BGP2 and BGP3 versions
of the Border Gateway Protocol. This recommendation only applies to BGP2
and BGP3 versions of the Border Gateway Protocol since starting with the
BGP4 version a default route advertisement capability is built in the
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1397.txt"
}

@TECHREPORT{rfc1398,
AUTHOR="F. Kastenholz",
TITLE="Definitions of Managed Objects for the {Ethernet-Like} Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1398,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing ethernet-like
objects.",
URL="http://www.rfc-editor.org/rfc/rfc1398.txt"
}

@TECHREPORT{rfc1400,
AUTHOR="S. Williamson",
TITLE="Transition and Modernization of the Internet Registration Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1400,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="As a result of the NREN NIS award by National Science
Foundation, non- DDN registration services will soon be transferred from
the DDN NIC to the new Internet Registration Service, which is a part of
an entity referred to as the InterNIC.",
URL="http://www.rfc-editor.org/rfc/rfc1400.txt"
}

@TECHREPORT{rfc1401,
AUTHOR="Internet Activities Board",
TITLE="Correspondence between the {IAB} and {DISA} on the use of {DNS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1401,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT={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{"}.},
URL="http://www.rfc-editor.org/rfc/rfc1401.txt"
}

@TECHREPORT{rfc1402,
AUTHOR="J. Martin",
TITLE="There's Gold in them thar Networks! or Searching for Treasure in all the
Wrong Places",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1402,
PAGES=39,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1402.txt"
}

@TECHREPORT{rfc1403,
AUTHOR="K. Varadhan",
TITLE="{BGP} {OSPF} Interaction",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1403,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1403.txt"
}

@TECHREPORT{rfc1404,
AUTHOR="B. Stockman",
TITLE="A Model for Common Operational Statistics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1404,
PAGES=27,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This memo describes a model for operational statistics in the
Internet. It gives recommendations for metrics, measurements, polling
periods, storage formats and presentation formats.",
URL="http://www.rfc-editor.org/rfc/rfc1404.txt"
}

@TECHREPORT{rfc1405,
AUTHOR="C. Allocchio",
TITLE="Mapping between {X.400(1984/1988)} and Mail-11 {(DECnet} mail)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1405,
PAGES=19,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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. 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. 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. This is a combined effort of
COSINE S2.2, the RARE MSG Working Group, and the IETF X.400 Ops Working
Group.",
URL="http://www.rfc-editor.org/rfc/rfc1405.txt"
}

@TECHREPORT{rfc1406,
EDITOR="F. Baker and J. Watt",
TITLE="Definitions of Managed Objects for the {DS1} and {E1} Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1406,
PAGES=50,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing DS1 Interfaces
-- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1406.txt"
}

@TECHREPORT{rfc1407,
AUTHOR="T. F. Cox and K. Tesink",
TITLE="Definitions of Managed Objects for the {DS3/E3} Interface Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1407,
PAGES=43,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1407.txt"
}

@TECHREPORT{rfc1408,
EDITOR="D. Borman",
TITLE="Telnet Environment Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1408,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1408.txt"
}

@TECHREPORT{rfc1409,
AUTHOR="Editor D. Borman",
EDITOR="D. Borman",
TITLE="Telnet Authentication Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1409,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This memo defines an Experimental Protocol for the Internet
community.",
URL="http://www.rfc-editor.org/rfc/rfc1409.txt"
}

@TECHREPORT{rfc1410,
EDITOR="J. B. Postel",
TITLE="{IAB} Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1410,
PAGES=35,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="Discussion of the standardization process and the RFC document
series is presented first, followed by an explanation of the terms.
Sections 6.2 - 6.9 contain the lists of protocols in each stage of
standardization. Finally come pointers to references and contacts for
further information. This memo is intended to be issued approximately
quarterly; please be sure the copy you are reading is current. Current
copies may be obtained from the Network Information Center or from the
Internet Assigned Numbers Authority (see the contact information at the
end of this memo). Do not use this edition after 31-July-93. See Section
6.1 for a description of recent changes. In the official lists in
sections 6.2 - 6.9, 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.",
URL="http://www.rfc-editor.org/rfc/rfc1410.txt"
}

@TECHREPORT{rfc1411,
EDITOR="D. Borman",
TITLE="Telnet Authentication: Kerberos Version 4",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1411,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This memo defines an Experimental Protocol for the Internet
community.",
URL="http://www.rfc-editor.org/rfc/rfc1411.txt"
}

@TECHREPORT{rfc1412,
AUTHOR="K. Alagappan",
TITLE="Telnet Authentication: {SPX}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1412,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="This memo defines an Experimental Protocol for the Internet
community.",
URL="http://www.rfc-editor.org/rfc/rfc1412.txt"
}

@TECHREPORT{rfc1413,
AUTHOR="M. St. Johns",
TITLE="Identification Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1413,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT={The Identification Protocol (a.k.a., {"}ident{"}, a.k.a., {"}the
Ident Protocol{"}) provides a means to determine the identity of a user of
a particular TCP connection. Given a TCP port number pair, it returns a
character string which identifies the owner of that connection on the
server's system. The Identification Protocol was formerly called the
Authentication Server Protocol. It has been renamed to better reflect
its function. This document is a product of the TCP Client Identity
Protocol Working Group of the Internet Engineering Task Force (IETF).},
URL="http://www.rfc-editor.org/rfc/rfc1413.txt"
}

@TECHREPORT{rfc1414,
AUTHOR="M. St. Johns and M. P. Rose",
TITLE="Identification {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1414,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1414.txt"
}

@TECHREPORT{rfc1415,
AUTHOR="J. Mindel and R. Slaski",
TITLE="{FTP-FTAM} Gateway Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1415,
PAGES=58,
DAYS=15,
MONTH=jan,
YEAR=1993,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1415.txt"
}

@TECHREPORT{rfc1417,
AUTHOR=" {{North American Directory Forum}}",
TITLE="{NADF} Standing Documents: A Brief Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1417,
MONTH=feb,
YEAR=1993,
ABSTRACT="The North American Directory Forum (NADF) is a collection of
service providers which plans to cooperatively offer a Public Directory
Service in North America using the CCITT X.500 Recommendations. Although
many groups are working on realizing X.500, the NADF is unique in that
it must achieve a cooperative service offered by competing providers.
The purpose of this document is to provide a brief overview of the
NADF's Standing Document series. As of this writing, the standing
documents are:",
URL="http://www.rfc-editor.org/rfc/rfc1417.txt"
}

@TECHREPORT{rfc1418,
AUTHOR="M. P. Rose",
TITLE="{SNMP} over {OSI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1418,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="This memo addresses some concerns by defining a framework for
running the SNMP in an environment which supports the OSI
connectionless-mode transport service.",
URL="http://www.rfc-editor.org/rfc/rfc1418.txt"
}

@TECHREPORT{rfc1419,
AUTHOR="G. Minshall and M. Ritter",
TITLE="{SNMP} over {AppleTalk}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1419,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="This memo describes the method by which the Simple Network
Management Protocol (SNMP) as specified in RFC XXX can be used over
AppleTalk protocols instead of the Internet UDP/IP protocol stack. This
specification is useful for network elements which have AppleTalk
support but lack TCP/IP support. It should be noted that if a network
element supports multiple protocol stacks, and UDP is available, it is
the preferred network layer to use. SNMP has been successful in managing
Internet capable network elements which support the protocol stack at
least through UDP, the connectionless Internet transport layer protocol.
As originally designed, SNMP is capable of running over any reasonable
transport mechanism (not necessarily a transport protocol) that supports
bi- directional flow and addressability. Many non-Internet capable
network elements are present in networks. Some of these elements are
equipped with the AppleTalk protocols. One method of using SNMP to
manage these elements is to define a method of transmitting an SNMP
message inside an AppleTalk protocol data unit. This RFC is the product
of the SNMP over a Multi-protocol Internet Working Group of the Internet
Engineering Task Force (IETF).",
URL="http://www.rfc-editor.org/rfc/rfc1419.txt"
}

@TECHREPORT{rfc1420,
AUTHOR="S. Bostock",
TITLE="{SNMP} over {IPX}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1420,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1420.txt"
}

@TECHREPORT{rfc1421,
AUTHOR="J. R. Linn",
TITLE="Privacy Enhancement for Internet Electronic Mail: Part {I:} Message
Encryption and Authentication Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1421,
PAGES=42,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="This document defines message encryption and authentication
procedures, in order to provide privacy-enhanced mail (PEM) services for
electronic mail transfer in the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1421.txt"
}

@TECHREPORT{rfc1422,
AUTHOR="S. A. Kent",
TITLE="Privacy Enhancement for Internet Electronic Mail: Part {II:}
{Certificate-Based} Key Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1422,
PAGES=32,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="This is one of a series of documents defining privacy
enhancement mechanisms for electronic mail transferred using Internet
mail protocols.",
URL="http://www.rfc-editor.org/rfc/rfc1422.txt"
}

@TECHREPORT{rfc1423,
AUTHOR="D. Balenson",
TITLE="Privacy Enhancement for Internet Electronic Mail: Part {III:} Algorithms,
Modes, and Identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1423,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="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). 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1423.txt"
}

@TECHREPORT{rfc1424,
AUTHOR="B. Kaliski",
TITLE="Privacy Enhancement for Internet Electronic Mail: Part {IV:} Key
Certification and Related Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1424,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="This document describes three types of service in support of
Internet Privacy-Enhanced Mail (PEM): key certification, certificate-
revocation list (CRL) storage, and CRL retrieval.",
URL="http://www.rfc-editor.org/rfc/rfc1424.txt"
}

@TECHREPORT{rfc1425,
EDITOR="J. Klensin and Wg Chair and N. Freed",
TITLE="{SMTP} Service Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1425,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1425.txt"
}

@TECHREPORT{rfc1426,
EDITOR="J. Klensin and Wg Chair and N. Freed",
TITLE="{SMTP} Service Extension for {8bit-MIMEtransport}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1426,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1426.txt"
}

@TECHREPORT{rfc1427,
EDITOR="J. Klensin and Wg Chair and N. Freed",
TITLE="{SMTP} Service Extension for Message Size Declaration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1427,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1427.txt"
}

@TECHREPORT{rfc1428,
AUTHOR="G. M. Vaudreuil",
TITLE="Transition of Internet Mail from {Just-Send-8} to {8bit-SMTP/MIME}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1428,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1428.txt"
}

@TECHREPORT{rfc1429,
AUTHOR="E. Thomas",
TITLE="Listserv Distribute Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1429,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1429.txt"
}

@TECHREPORT{rfc1430,
AUTHOR="S. E. Hardcastle-Kille and E. Huizer and V. G. Cerf and R. Hobby and S. A.
Kent",
TITLE="A Strategic Plan for Deploying an Internet {X.500} Directory Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1430,
PAGES=20,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1430.txt"
}

@TECHREPORT{rfc1431,
AUTHOR="P. Barker",
TITLE="{DUA} Metrics {(OSI-DS} 33 (v2))",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1431,
PAGES=19,
DAYS=15,
MONTH=feb,
YEAR=1993,
ABSTRACT={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. 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. Please send
comments to the author or to the discussion group <osi-
ds(at)CS.UCL.AC.UK>.},
URL="http://www.rfc-editor.org/rfc/rfc1431.txt"
}

@TECHREPORT{rfc1432,
AUTHOR="J. S. Quarterman",
TITLE="Recent Internet Books",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1432,
PAGES=15,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1432.txt"
}

@TECHREPORT{rfc1433,
AUTHOR="J. Garrett and J. Hagan and J. W. Wong",
TITLE="Directed {ARP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1433,
PAGES=18,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1433.txt"
}

@TECHREPORT{rfc1434,
AUTHOR="R. C. Dixon and D. Kushi",
TITLE="Data Link Switching: {Switch-to-Switch} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1434,
PAGES=33,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="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. Any questions or comments relative to
the contents of this RFC should be sent to the following Internet
address: dlsw(at)ralvma.vnet.ibm.com.",
URL="http://www.rfc-editor.org/rfc/rfc1434.txt"
}

@TECHREPORT{rfc1435,
AUTHOR="S. Knowles",
TITLE="{IESG} Advice from Experience with Path {MTU} Discovery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1435,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1435.txt"
}

@TECHREPORT{rfc1436,
AUTHOR="F. Anklesaria and M. McCahill and P. Lindner and D. B. Johnson and D.
Torrey and B. Albert",
TITLE="The Internet Gopher Protocol (a distributed document search and retrieval
protocol)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1436,
PAGES=16,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1436.txt"
}

@TECHREPORT{rfc1437,
AUTHOR="N. Borenstein and M. Linimon",
TITLE="The Extension of {MIME} {Content-Types} to a New Medium",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1437,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1437.txt"
}

@TECHREPORT{rfc1438,
AUTHOR="A. Lyman Chapin and C. Huitema",
TITLE="Internet Engineering Task Force Statements Of Boredom {(SOBs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1438,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="The current IETF process has two types of RFCs: standards
track documents and other RFCs (e.g., informational, experimental,
FYIs). The intent of the standards track documents is clear, and
culminates in an official Internet Standard. Informational RFCs can be
published on a less formal basis, subject to the reasonable constraints
of the RFC Editor. Informational RFCs are not subject to peer review and
carry no significance whatsoever within the IETF process.",
URL="http://www.rfc-editor.org/rfc/rfc1438.txt"
}

@TECHREPORT{rfc1439,
AUTHOR="C. Finseth",
TITLE="The Uniqueness of Unique Identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1439,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=1993,
ABSTRACT="This RFC provides information that may be useful when
selecting a method to use for assigning unique identifiers to people.",
URL="http://www.rfc-editor.org/rfc/rfc1439.txt"
}

@TECHREPORT{rfc1440,
AUTHOR="R. Troth",
TITLE="{SIFT/UFT:} {Sender-Initiated/Unsolicited} File Transfer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1440,
PAGES=9,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT={This document describes a Sender-Initiated File Transfer
(SIFT) protocol, also commonly called Unsolicited File Transfer (UFT)
protocol. The acronyms SIFT and UFT are synonymous throughout this
document. The term {"}unsolicited{"} does not imply that the file is
unwanted, but that the receiver did not initiate the transaction.
Sender-Initiated File Transfer contrasts with other file transfer
methods in that the sender need not have an account or any registration
on the target host system, and the receiving user may have less steps to
take to retrieve the file(s) sent. Unlike traditional file transfer, UFT
lends itself handily to background or deferred operation, though it may
be carried out immediately, even interactively.},
URL="http://www.rfc-editor.org/rfc/rfc1440.txt"
}

@TECHREPORT{rfc1441,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Introduction to version 2 of the Internet-standard Network Management
Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1441,
PAGES=13,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="The purpose of this document is to provide an overview of
version 2 of the Internet-standard Network Management Framework, termed
the SNMP version 2 framework (SNMPv2).",
URL="http://www.rfc-editor.org/rfc/rfc1441.txt"
}

@TECHREPORT{rfc1442,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Structure of Management Information for version 2 of the Simple Network
Management Protocol {(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1442,
PAGES=54,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined in
MIB modules. These modules are written using a subset of OSI's Abstract
Syntax Notation One (ASN.1). It is the purpose of this document, the
Structure of Management Information (SMI), to define that subset.",
URL="http://www.rfc-editor.org/rfc/rfc1442.txt"
}

@TECHREPORT{rfc1443,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Textual Conventions for version 2 of the Simple Network Management Protocol
{(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1443,
PAGES=31,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="It is the purpose of this document to define the initial set
of textual conventions available to all MIB modules.",
URL="http://www.rfc-editor.org/rfc/rfc1443.txt"
}

@TECHREPORT{rfc1444,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Conformance Statements for version 2 of the Simple Network Management
Protocol {(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1444,
PAGES=32,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="It may be useful to define the acceptable lower-bounds of
implementation, along with the actual level of implementation achieved.
It is the purpose of this document to define the notation used for these
purposes.",
URL="http://www.rfc-editor.org/rfc/rfc1444.txt"
}

@TECHREPORT{rfc1445,
AUTHOR="J. Galvin and K. McCloghrie",
TITLE="Administrative Model for version 2 of the Simple Network Management
Protocol {(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1445,
PAGES=47,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="It is the purpose of this document, the Administrative Model
for SNMPv2, to define how the administrative framework is applied to
realize effective network management in a variety of configurations and
environments",
URL="http://www.rfc-editor.org/rfc/rfc1445.txt"
}

@TECHREPORT{rfc1446,
AUTHOR="J. Galvin and K. McCloghrie",
TITLE="Security Protocols for version 2 of the Simple Network Management Protocol
{(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1446,
PAGES=51,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="It is the purpose of this document, Security Protocols for
SNMPv2, to define one such authentication and one such privacy protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1446.txt"
}

@TECHREPORT{rfc1447,
AUTHOR="K. McCloghrie and J. Galvin",
TITLE="Party {MIB} for version 2 of the Simple Network Management Protocol
{(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1447,
PAGES=50,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="The Administrative Model for SNMPv2 document defines the
properties associated with SNMPv2 parties, SNMPv2 contexts, and access
control policies. It is the purpose of this document, the Party MIB for
SNMPv2, to define managed objects which correspond to these properties.",
URL="http://www.rfc-editor.org/rfc/rfc1447.txt"
}

@TECHREPORT{rfc1448,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Protocol Operations for version 2 of the Simple Network Management Protocol
{(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1448,
PAGES=35,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="It is the purpose of this document, Protocol Operations for
SNMPv2, to define the operations of the protocol with respect to the
sending and receiving of the PDUs.",
URL="http://www.rfc-editor.org/rfc/rfc1448.txt"
}

@TECHREPORT{rfc1449,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Transport Mappings for version 2 of the Simple Network Management Protocol
{(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1449,
PAGES=24,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="It is the purpose of this document to define how the SNMPv2
maps onto an initial set of transport domains.",
URL="http://www.rfc-editor.org/rfc/rfc1449.txt"
}

@TECHREPORT{rfc1450,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Management Information Base for version 2 of the Simple Network Management
Protocol {(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1450,
PAGES=27,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="It is the purpose of this document to define managed objects
which describe the behavior of a SNMPv2 entity.",
URL="http://www.rfc-editor.org/rfc/rfc1450.txt"
}

@TECHREPORT{rfc1451,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="{Manager-to-Manager} Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1451,
PAGES=36,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="It is the purpose of this document to define managed objects
which describe the behavior of a SNMPv2 entity acting in both a manager
role and an agent role.",
URL="http://www.rfc-editor.org/rfc/rfc1451.txt"
}

@TECHREPORT{rfc1452,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Coexistence between version 1 and version 2 of the Internet-standard
Network Management Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1452,
PAGES=17,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="The purpose of this document is to describe coexistence
between version 2 of the Internet-standard Network Management Framework,
termed the SNMP version 2 framework (SNMPv2), and the original
Internet-standard Network Management Framework (SNMPv1).",
URL="http://www.rfc-editor.org/rfc/rfc1452.txt"
}

@TECHREPORT{rfc1453,
AUTHOR="W. Chimiak",
TITLE="A Comment on Packet Video Remote Conferencing and the {Transport/Network}
Layers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1453,
PAGES=10,
DAYS=15,
MONTH=apr,
YEAR=1993,
ABSTRACT="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 (RFC 988), and
VMTP (RFC 1045) were 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.",
URL="http://www.rfc-editor.org/rfc/rfc1453.txt"
}

@TECHREPORT{rfc1454,
AUTHOR="T. Dixon",
TITLE="Comparison of Proposals for Next Version of {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1454,
PAGES=15,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT={This is a slightly edited reprint of RARE Technical Report
(RTC(93)004). 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. The paper begins with a
{"}generic{"} discussion of the mechanisms for solving problems and
achieving particular goals, before discussing the proposals invidually.},
URL="http://www.rfc-editor.org/rfc/rfc1454.txt"
}

@TECHREPORT{rfc1455,
AUTHOR="D. Eastlake 3rd",
TITLE="Physical Link Security Type of Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1455,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1455.txt"
}

@TECHREPORT{rfc1456,
AUTHOR=" {{Vietnamese Standardization Working Group}}",
TITLE="Conventions for Encoding the Vietnamese Language {VISCII:} {VIetnamese}
Standard Code for Information Interchange {VIQR:} {VIetnamese}
{Quoted-Readable} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1456,
MONTH=may,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1456.txt"
}

@TECHREPORT{rfc1457,
AUTHOR="R. Housley",
TITLE="Security Label Framework for the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1457,
PAGES=14,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT="This memo presents a security labeling framework for the
Internet. The framework is intended to help protocol designers determine
what, if any, security labeling should be supported by their protocols.",
URL="http://www.rfc-editor.org/rfc/rfc1457.txt"
}

@TECHREPORT{rfc1458,
AUTHOR="R. Braudes and S. Zabele",
TITLE="Requirements for Multicast Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1458,
PAGES=19,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT="Multicast protocols have been developed over the past several
years to address issues of group communication. Experience has
demonstrated that current protocols do not address all of the
requirements of multicast applications. This memo discusses some of
these unresolved issues, and provides a high-level design for a new
multicast transport protocol, group address and membership authority,
and modifications to existing routing protocols.",
URL="http://www.rfc-editor.org/rfc/rfc1458.txt"
}

@TECHREPORT{rfc1459,
AUTHOR="J. Oikarinen and D. P. Reed",
TITLE="Internet Relay Chat Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1459,
PAGES=65,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT="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. The IRC protocol is a text-based protocol, with the simplest
client being any socket program capable of connecting to the server.",
URL="http://www.rfc-editor.org/rfc/rfc1459.txt"
}

@TECHREPORT{rfc1460,
AUTHOR="M. P. Rose",
TITLE="Post Office Protocol - Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1460,
PAGES=17,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="This memo is a revision to RFC 1225, a Draft Standard. It
makes the following changes from that document: - the RPOP facility is
removed; - the optional APOP facility is added (which is in
interoperable, operational use in at least three implementations); - a
typo was corrected with respect to the interaction of LAST and RSET; -
section numbers were added; and, - an acknowledgements section was
added.",
URL="http://www.rfc-editor.org/rfc/rfc1460.txt"
}

@TECHREPORT{rfc1461,
AUTHOR="D. Throop",
TITLE="{SNMP} {MIB} extension for Multiprotocol Interconnect over {X.25}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1461,
PAGES=21,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT={This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing 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.},
URL="http://www.rfc-editor.org/rfc/rfc1461.txt"
}

@TECHREPORT{rfc1462,
AUTHOR="E. Krol and E. Hoffman",
TITLE={{FYI} on {"}What is the Internet?{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1462,
PAGES=11,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1462.txt"
}

@TECHREPORT{rfc1463,
AUTHOR="E. Hoffman and L. Jackson",
TITLE="{FYI} on Introducing the Internet-- A Short Bibliography of Introductory
Internetworking Readings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1463,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1463.txt"
}

@TECHREPORT{rfc1464,
AUTHOR="R. Rosenbaum",
TITLE="Using the Domain Name System To Store Arbitrary String Attributes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1464,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1464.txt"
}

@TECHREPORT{rfc1465,
AUTHOR="D. Eppenberger",
TITLE="Routing Coordination for {X.400} {MHS} Services Within a Multi Protocol /
Multi Network Environment Table Format {V3} for Static Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1465,
PAGES=31,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT="The usage of the X.400 Message Handling System (MHS) is
growing rapidly, especially in the commercial world but much interest
can also be found in the academic and research community. New networks
and new addresses come into use each and every day. The underlying
technology for different X.400 networks can vary depending on the
transport network and the X.400 MHS implementations used. As a large
number of X.400 implementations now support multiple stacks, this offers
the chance of implementing a world wide message handling service using
the same electronic mail standard and, therefore, without the need of
gateways with service reduction and without the restriction to a single
common transport network. This, however, leads to several problems for
the MHS manager, two of which are: - Where do I route new X.400
addresses and - How do I connect to a MHS domain that uses an underlying
technology that I do not support. This document proposes short term
solutions to these problems. It proposes a strategy for maintaining and
distributing routing information and shows how messages can travel over
different networks by using multi stack MTAs as relays. Document formats
and coordination procedures bridge the gap until an X.500 directory
service is ready to store the needed connectivity and routing
information. The format has been designed to allow the information to be
stored in an X.500 directory service while managers without directory
service access may still use a table based approach. The routing
structure proposed can be applied to a global MHS service",
URL="http://www.rfc-editor.org/rfc/rfc1465.txt"
}

@TECHREPORT{rfc1466,
AUTHOR="E. Gerich",
TITLE="Guidelines for Management of {IP} Address Space",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1466,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1466.txt"
}

@TECHREPORT{rfc1467,
AUTHOR="C. Topolcic",
TITLE="Status of {CIDR} Deployment in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1467,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1467.txt"
}

@TECHREPORT{rfc1468,
AUTHOR="J. Murai and M. R. Crispin and  ",
TITLE="Japanese Character Encoding for Internet Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1468,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT={This document describes the encoding used in electronic mail
(RFC 822) and network news (RFC1036) messages in several Japanese
networks. It was first specified by and used in JUNET. The encoding is
now also widely used in Japanese IP communities. The name given to this
encoding is {"}ISO-2022-JP{"}, which is intended to be used in the
{"}charset{"}
parameter field of MIME headers (see RFC 1341 and RFC 1342).},
URL="http://www.rfc-editor.org/rfc/rfc1468.txt"
}

@TECHREPORT{rfc1469,
AUTHOR="T. Pusateri",
TITLE="{IP} Multicast over {Token-Ring} Local Area Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1469,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1469.txt"
}

@TECHREPORT{rfc1470,
AUTHOR="R. Enger and J. F. Reynolds",
TITLE="{FYI} on a Network Management Tool Catalog: Tools for Monitoring and
Debugging {TCP/IP} Internets and Interconnected Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1470,
PAGES=192,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="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(at)merit.edu.",
URL="http://www.rfc-editor.org/rfc/rfc1470.txt"
}

@TECHREPORT{rfc1471,
AUTHOR="F. Kastenholz",
TITLE="The Definitions of Managed Objects for the Link Control Protocol of the
{Point-to-Point} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1471,
PAGES=25,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it 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.",
URL="http://www.rfc-editor.org/rfc/rfc1471.txt"
}

@TECHREPORT{rfc1472,
AUTHOR="F. Kastenholz",
TITLE="The Definitions of Managed Objects for the Security Protocols of the
{Point-to-Point} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1472,
PAGES=13,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it describes managed objects used for managing
the Security Protocols on subnetwork interfaces using the family of
Point-to-Point Protocols.",
URL="http://www.rfc-editor.org/rfc/rfc1472.txt"
}

@TECHREPORT{rfc1473,
AUTHOR="F. Kastenholz",
TITLE="The Definitions of Managed Objects for the {IP} Network Control Protocol of
the {Point-to-Point} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1473,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it describes managed objects used for managing
the IP Network Control Protocol on subnetwork interfaces using the
family of Point-to-Point Protocols.",
URL="http://www.rfc-editor.org/rfc/rfc1473.txt"
}

@TECHREPORT{rfc1474,
AUTHOR="F. Kastenholz",
TITLE="The Definitions of Managed Objects for the Bridge Network Control Protocol
of the {Point-to-Point} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1474,
PAGES=15,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it describes managed objects used for managing
the bridge Network Control Protocol on subnetwork interfaces using the
family of Point-to-Point Protocols.",
URL="http://www.rfc-editor.org/rfc/rfc1474.txt"
}

@TECHREPORT{rfc1475,
AUTHOR="R. Ullmann",
TITLE="{TP/IX:} The Next Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1475,
PAGES=35,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1475.txt"
}

@TECHREPORT{rfc1476,
AUTHOR="R. Ullmann",
TITLE="{RAP:} Internet Route Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1476,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1476.txt"
}

@TECHREPORT{rfc1477,
AUTHOR="M. Steenstrup",
TITLE="{IDPR} as a Proposed Standard",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1477,
PAGES=13,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="This document contains a discussion of inter-domain policy
routing (IDPR), including an overview of functionality and a discussion
of experiments. The objective of IDPR is to construct and maintain
routes between source and destination administrative domains, that
provide user traffic with the services requested within the constraints
stipulated for the domains transited. Four documents describe IDPR in
detail: M. Steenstrup. An architecture for inter-domain policy routing.
RFC 1478. July 1993. M. Steenstrup. Inter-domain policy routing protocol
specification: version 1. RFC 1479. July 1993. H. Bowns and M.
Steenstrup. Inter-domain policy routing configuration and usage. Work in
Progress. July 1991. R. Woodburn. Definitions of managed objects for
inter-domain policy routing (version 1). Work in Progress. March 1993.
This is a product of the Inter-Domain Policy Routing Working Group of
the Internet Engineering Task Force (IETF).",
URL="http://www.rfc-editor.org/rfc/rfc1477.txt"
}

@TECHREPORT{rfc1478,
AUTHOR="M. Steenstrup",
TITLE="An Architecture for {Inter-Domain} Policy Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1478,
PAGES=35,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1478.txt"
}

@TECHREPORT{rfc1479,
AUTHOR="M. Steenstrup",
TITLE="{Inter-Domain} Policy Routing Protocol Specification: Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1479,
PAGES=108,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1479.txt"
}

@TECHREPORT{rfc1480,
AUTHOR="A. Cooper and J. B. Postel",
TITLE="The {US} Domain",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1480,
PAGES=47,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT={The Domain Name System (DNS) provides for the translation
between hostnames and addresses. Within the Internet, this means
translating from a name such as {"}venera.isi.edu{"}, to an IP address such
as {"}128.9.0.32{"}. The DNS is a set of protocols and databases. The
protocols define the syntax and semantics for a query language to ask
questions about information located by DNS-style names. The databases
are distributed and replicated. There is no dependence on a single
central server, and each part of the database is provided in at least
two servers. The assignment of the 32-bit IP addresses is a separate
activity. IP addresses are delegated by the central Internet Registry to
regional authorities (such as the RIPE NCC for Europe) and the network
providers. To have a network number assigned please contact your network
service provider or regional registration authority. To determine who
this is (or as a last resort), you can contact the central Internet
Registry at Hostmaster(at)INTERNIC.NET. In addition to translating names to
addresses for hosts that are on the Internet, the DNS provides for
registering DNS-style names for other hosts reachable (via electronic
mail) through gateways or mail relays. The records for such name
registrations point to an Internet host (one with an IP address) that
acts as a mail forwarder for the registered host. For example, the host
{"}bah.rochester.ny.us{"} is registered in the DNS with a pointer to the
mail relay {"}relay1.uu.net{"}. This type of pointer is called an MX
record.
This gives electronic mail users a uniform mail addressing syntax and
avoids making users aware of the underlying network boundaries. The
reason for the development of the domain system was growth in the
Internet. The hostname to address mappings were maintained by the
InterNIC in a single file, called HOSTS.TXT, which was FTP'd by all the
hosts on the Internet. The network population was changing in character.
The time-share hosts that made up the original ARPANET were being
replaced with local networks of workstations. Local organizations were
administering their own names and addresses, but had to wait for the NIC
to make changes in HOSTS.TXT to make the changes visible to the Internet
at large. Organizations also wanted some local structure on the name
space. The applications on the Internet were getting more sophisticated
and creating a need for general purpose name service. The idea of a
hierarchical name space, with the hierarchy roughly corresponding to
organizational structure, and names using {"}.{"} as the character to mark
the boundary between hierarchy levels was developed. A design using a
distributed database and generalized resources was implemented.},
URL="http://www.rfc-editor.org/rfc/rfc1480.txt"
}

@TECHREPORT{rfc1481,
AUTHOR="C. Huitema",
TITLE="{IAB} Recommendation for an Intermediate Strategy to Address the Issue of
Scaling",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1481,
PAGES=2,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="CIDR is proposed as an immediate term strategy to extend the
life of the current 32 bit IP address space.",
URL="http://www.rfc-editor.org/rfc/rfc1481.txt"
}

@TECHREPORT{rfc1482,
AUTHOR="M. Knopper and S. Richardson",
TITLE="Aggregation Support in the {NSFNET} {Policy-Based} Routing Database",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1482,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1482.txt"
}

@TECHREPORT{rfc1483,
AUTHOR="Juha Heinanen",
TITLE="Multiprotocol Encapsulation over {ATM} Adaptation Layer 5",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1483,
PAGES=16,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1483.txt"
}

@TECHREPORT{rfc1484,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="Using the {OSI} Directory to achieve User Friendly Naming {(OSI-DS} 24
(v1.2))",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1484,
PAGES=25,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="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: A user oriented notation; Guessability. 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 RFC 1485 and it is
intended that these specifications are compatible. Please send comments
to the author or to the discussion group: osi-ds(at)CS.UCL.AC.UK.",
URL="http://www.rfc-editor.org/rfc/rfc1484.txt"
}

@TECHREPORT{rfc1485,
AUTHOR="S. E. Hardcastle-Kille",
TITLE="A String Representation of Distinguished Names {(OSI-DS} 23 (v5))",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1485,
PAGES=7,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="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 <osi-ds(at)CS.UCL.AC.UK>.",
URL="http://www.rfc-editor.org/rfc/rfc1485.txt"
}

@TECHREPORT{rfc1486,
AUTHOR="M. P. Rose and C. Malamud",
TITLE="An Experiment in Remote Printing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1486,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT={Although electronic mail is preferable as a means of
third-party communication, in some cases it may be necessary to print
information, in hard-copy form, at a remote location. The remote output
device may consist of a standard line printer, a printer with multiple
fonts and faces, a printer that can reproduce graphics, or a facsimile
device. Remote output may be accompanied by information that identifies
the intended recipient. This memo describes a technique for {"}remote
printing{"} using the Internet mail infrastructure. In particular, this
memo focuses on the case in which remote printers are connected to the
international telephone network. Furthermore, it describes an experiment
in remote printing.},
URL="http://www.rfc-editor.org/rfc/rfc1486.txt"
}

@TECHREPORT{rfc1487,
AUTHOR="W. Yeong and T. Howes and S. E. Kille",
TITLE="{X.500} Lightweight Directory Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1487,
PAGES=21,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="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. Key aspects of LDAP are:
- Protocol elements are carried directly over TCP or other transport,
bypassing much of the session/presentation overhead. - Many protocol
data elements are encoding as ordinary strings (e.g., Distinguished
Names). - A lightweight BER encoding is used to encode all protocol
elements.",
URL="http://www.rfc-editor.org/rfc/rfc1487.txt"
}

@TECHREPORT{rfc1488,
AUTHOR="T. Howes and S. E. Kille and W. Yeong and C. Robbins",
TITLE="The {X.500} String Representation of Standard Attribute Syntaxes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1488,
PAGES=11,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="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 RFC XXX.",
URL="http://www.rfc-editor.org/rfc/rfc1488.txt"
}

@TECHREPORT{rfc1489,
AUTHOR="A. Chernov",
TITLE="Registration of a Cyrillic Character Set",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1489,
PAGES=5,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT={Though the proposed character set {"}koi8-r{"} is not currently an
international standard, there is very large user community (including
Relcom Net) supporting it. Factually, {"}koi8-r{"} is de-facto standard for
Unix and global network applications in the former Soviet Union. This is
the reason the Society of Unix User Groups (SUUG) believes {"}koi8-r{"}
should be registered. MIME character set name: koi8-r Published
specification: This standard is unpublished, but based on several
published standards: GOST 19768-74 (old-koi8), ISO 6937/8 (not
registered) and variations: INIS-cyrillic, ISO 5427.},
URL="http://www.rfc-editor.org/rfc/rfc1489.txt"
}

@TECHREPORT{rfc1490,
AUTHOR="T. T. Bradley and C. M. Brown and A. Malis",
TITLE="Multiprotocol Interconnect over Frame Relay",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1490,
PAGES=35,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1490.txt"
}

@TECHREPORT{rfc1491,
AUTHOR="C. Weider and R. Wright",
TITLE="A Survey of Advanced Usages of {X.500}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1491,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1491.txt"
}

@TECHREPORT{rfc1492,
AUTHOR="C. Finseth",
TITLE="An Access Control Protocol, Sometimes Called {TACACS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1492,
PAGES=21,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="This RFC documents the extended TACACS protocol use by the
Cisco Systems terminal servers. This same protocol is used by the
University of Minnesota's distributed authentication system. This memo
provides information for the Internet community. It does not specify an
Internet standard.",
URL="http://www.rfc-editor.org/rfc/rfc1492.txt"
}

@TECHREPORT{rfc1493,
AUTHOR="E. Decker and P. Langille and A. Rijsinghani and K. McCloghrie",
TITLE="Definitions of Managed Objects for Bridges",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1493,
PAGES=34,
DAYS=15,
MONTH=jul,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular it defines objects for managing MAC bridges
based on the IEEE 802.1D-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.",
URL="http://www.rfc-editor.org/rfc/rfc1493.txt"
}

@TECHREPORT{rfc1494,
AUTHOR="H. Alvestrand and S. Thompson",
TITLE="Equivalences between 1988 {X.400} and {RFC-822} Message Bodies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1494,
PAGES=19,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT={This document is a companion to RFC XXX, which defines the
principles behind interworking between MIME-based RFC-822 mail and X.400
mail. This document describes the content of the {"}IANA MHS/MIME
Equivalence table{"} referenced in the companion document, and defines the
initial configuration of this table. Mappings for new MIME content-types
and/or X.400 body part types should be registered with the IANA to
minimize redundancy and promote interoperability. In MIME, the term
{"}content-type{"} is used to refer to an information object contained in
the body of a message. In contrast, X.400 uses the term {"}body part
type.{"} In this document, the term {"}body part{"} is used to refer to
either. Please send comments to the MIME-MHS mailing list:
<mime-mhs(at)surfnet.nl>.},
URL="http://www.rfc-editor.org/rfc/rfc1494.txt"
}

@TECHREPORT{rfc1495,
AUTHOR="H. Alvestrand and S. E. Kille and R. Miles and M. P. Rose and S. Thompson",
TITLE="Mapping between {X.400} and {RFC-822} Message Bodies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1495,
PAGES=11,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT={The Internet community is a large collection of networks under
autonomous administration, but sharing a core set of protocols. These
are known as the Internet suite of protocols (or simply {"}TCP/IP{"}). Use
of electronic-mail in the Internet is defined primarily by one},
URL="http://www.rfc-editor.org/rfc/rfc1495.txt"
}

@TECHREPORT{rfc1496,
AUTHOR="H. Alvestrand and J. Romaguera and K. Jordan",
TITLE="Rules for downgrading messages from {X.400/88} to {X.400/84} when {MIME}
content-types are present in the messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1496,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT="Interworking between X.400(88) and MIME is achieved by RFC
XXX, which complements RFC-1327, which in turn specifies the
interworking between X.400(88) and RFC-822 based mail. Interworking
between X.400(88) and X.400 (84) is achieved by RFC-1328. That document
does not describe what to do in the case where body parts arrive at the
gateway that cannot be adequately represented in the X.400(84) system.
This document describes how RFC-1328 must be modified in order to
provide adequate support for the scenarios: SMTP(MIME) -> X.400(84)
X.400(84) -> SMTP(MIME)",
URL="http://www.rfc-editor.org/rfc/rfc1496.txt"
}

@TECHREPORT{rfc1498,
AUTHOR="J. H. Saltzer",
TITLE="On the Naming and Binding of Network Destinations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1498,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1498.txt"
}

@TECHREPORT{rfc1500,
AUTHOR="Editor J. Postel",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1500,
PAGES=36,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT="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.9 contain the lists of protocols in each stage
of standardization. Finally are pointers to references and contacts for
further information. This memo is intended to be issued approximately
quarterly; please be sure the copy you are reading is current. Current
copies may be obtained from the Network Information Center (INTERNIC) or
from the Internet Assigned Numbers Authority (IANA) (see the contact
information at the end of this memo). Do not use this edition after
31-October-93. See Section 6.1 for a description of recent changes. In
the official lists in sections 6.2 - 6.9, 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.",
URL="http://www.rfc-editor.org/rfc/rfc1500.txt"
}

@TECHREPORT{rfc1501,
AUTHOR="E. Brunsen",
TITLE="{OS/2} User Group",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1501,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT="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. There is a group called The Phoenix
Group which is in the process of determining the need for a national
OS/2 users' group. This group is targeted for the *individual* user of
OS/2, and is designed to provide an effective vehicle through which
users can communicate their desires for OS/2 to IBM. If you work in the
corporate Information Technology world, you are no doubt familiar with
organizations such as SHARE, GUIDE, COMMON and DECIUS, among many. These
organizations serve as a focal point for users, and represent a combined
voice to IBM (SHARE, GUIDE and COMMON) and Digital Equipment Company
(DECIUS). The intent of these organizations is to work closely with
their respective hardware/software providers to influence their
direction of their products, be they operating systems or CPU's. To this
end, many of us in other electronic fora believe that there is no
representative voice for the end-user of OS/2 with IBM. Thus, The
Phoenix Group, is taking a straw poll of OS/2 users in many different
electronic fora to determine the need for, and membership potential for
such an organization. The founding council of The Phoenix Group consists
of the following individuals: Mike Andrews, Eric Brunsen, Max Eidswick,
Robin Frank, Stan Hawkins, Jack Hiatt, Bob Holmes, Wayne Holmes, John
Schaeffer, and Toby Pennycuff You may recognize some of the names in
this group, and you may not. However, we are all long-time users of
OS/2, and all believe that",
URL="http://www.rfc-editor.org/rfc/rfc1501.txt"
}

@TECHREPORT{rfc1502,
AUTHOR="H. Alvestrand",
TITLE="{X.400} Use of Extended Character Sets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1502,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT={Since 1988, X.400 has had the capacity for carrying a large
number of different character sets in a message by using the body part
{"}GeneralText{"} defined by ISO/IEC 10021-7. Since 1992, the Internet also
has the means of passing around messages containing multiple character
sets, by using the mechanism defined in RFC-MIME. This RFC defines a
suggested method of using {"}GeneralText{"} in order to harmonize as much
as
possible the usage of this body part.},
URL="http://www.rfc-editor.org/rfc/rfc1502.txt"
}

@TECHREPORT{rfc1503,
AUTHOR="K. McCloghrie and M. P. Rose",
TITLE="Algorithms for Automating Administration in {SNMPv2} Managers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1503,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT="When a user invokes an SNMPv2 management application, it may
be desirable for the user to specify the minimum amount of information
necessary to establish and maintain SNMPv2 communications. This memo
suggests an approach to achieve this goal.",
URL="http://www.rfc-editor.org/rfc/rfc1503.txt"
}

@TECHREPORT{rfc1504,
AUTHOR="A. Oppenheimer",
TITLE="Appletalk {Update-Based} Routing Protocol: Enhanced Appletalk Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1504,
PAGES=82,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT="This memo is being distributed to members of the Internet
community to fully document an Apple protocol that may be running over
the 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 implementers.",
URL="http://www.rfc-editor.org/rfc/rfc1504.txt"
}

@TECHREPORT{rfc1505,
AUTHOR="A. Costanzo and D. Robinson and R. Ullmann",
TITLE="Encoding Header Field for Internet Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1505,
PAGES=36,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT="This document expands upon the elective experimental Encoding
header field which permits the mailing of multi-part, multi-structured
messages. It replaces RFC 1154.",
URL="http://www.rfc-editor.org/rfc/rfc1505.txt"
}

@TECHREPORT{rfc1506,
AUTHOR="J. Houttuin",
TITLE="A Tutorial on Gatewaying between {X.400} and Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1506,
PAGES=39,
DAYS=15,
MONTH=aug,
YEAR=1993,
ABSTRACT={There are many ways in which X.400 and Internet (STD 11, RFC
822) mail systems can be interconnected. Addresses and service elements
can be mapped onto each other in different ways. From the early
available gateway implementations, one was not necessarily better than
another, but the sole fact that each handled the mappings in a different
way led to major interworking problems, especially when a message (or
address) crossed more than one gateway. The need for one global standard
on how to implement X.400 - Internet mail gatewaying was satisfied by
the Internet Request For Comments 1327, titled {"}Mapping between
X.400(1988)/ISO 10021 and RFC 822.{"} This tutorial was produced
especially to help new gateway managers find their way into the
complicated subject of mail gatewaying according to RFC 1327. The need
for such a tutorial can be illustrated by quoting the following
discouraging paragraph from RFC 1327, chapter 1: {"}Warning: the remainder
of this specification is technically detailed. It will not make sense,
except in the context of RFC 822 and X.400 (1988). Do not attempt to
read this document unless you are familiar with these specifications.{"}
The introduction of this tutorial is general enough to be read not only
by gateway managers, but also by e-mail managers who are new to
gatewaying or to one of the two e-mail worlds in general. Parts of this
introduction can be skipped as needed. For novice end-users, even this
tutorial will be difficult to read. They are encouraged to use the
COSINE MHS pocket user guide instead. To a certain extent, this document
can also be used as a reference guide to X.400 <-> RFC 822 gatewaying.
Wherever there is a lack of detail in the tutorial, it will at least
point to the corresponding chapters in other documents. As such, it
shields the RFC 1327 novice},
URL="http://www.rfc-editor.org/rfc/rfc1506.txt"
}

@TECHREPORT{rfc1507,
AUTHOR="C. Kaufman",
TITLE="{DASS} - Distributed Authentication Security Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1507,
PAGES=119,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="The goal of DASS is to provide authentication services in a
distributed environment which are both more secure and easier to use
than existing mechanisms.",
URL="http://www.rfc-editor.org/rfc/rfc1507.txt"
}

@TECHREPORT{rfc1508,
AUTHOR="J. R. Linn",
TITLE="Generic Security Service Application Program Interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1508,
PAGES=49,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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: documents defining specific parameter bindings
for particular language environments documents defining token formats,
protocols, and procedures to be implemented in order to realize GSS-API
services atop particular security mechanisms",
URL="http://www.rfc-editor.org/rfc/rfc1508.txt"
}

@TECHREPORT{rfc1509,
AUTHOR="J. Wray",
TITLE="Generic Security Service {API} : C-bindings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1509,
PAGES=48,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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.
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.",
URL="http://www.rfc-editor.org/rfc/rfc1509.txt"
}

@TECHREPORT{rfc1510,
AUTHOR="J. Kohl and C. Neuman",
TITLE="The Kerberos Network Authentication Service {(V5)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1510,
PAGES=112,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1510.txt"
}

@TECHREPORT{rfc1511,
AUTHOR="J. R. Linn",
TITLE="Common Authentication Technology Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1511,
PAGES=2,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="The IETF's Common Authentication Technology (CAT) working
group has pursued, and continues to pursue, several interrelated
activities, involving definition of service interfaces as well as
protocols. As a goal, it has sought to separate security implementation
tasks from integration of security data elements into caller protocols,
enabling those tasks to be partitioned and performed separately by
implementors with different areas of expertise. This strategy is
intended to provide leverage for the IETF community's security- oriented
resources (by allowing a single security implementation to be integrated
with, and used by, multiple caller protocols), and to allow protocol
implementors to focus on the functions that their protocols are designed
to provide rather than on characteristics of particular security
mechanisms (by defining an abstract service which multiple mechanisms
can realize). The CAT WG has worked towards agreement on a common
service interface, (the Generic Security Service Application Program
Interface, or GSS-API), allowing callers to invoke security functions,
and also towards agreement on a common security token format
incorporating means to identify the mechanism type in conjunction with
which security data elements should be interpreted. The GSS-API,
comprising a mechanism-independent model for security integration,
provides authentication services (peer entity authentication) to a
variety of protocol callers in a manner which insulates those callers
from the specifics of underlying security mechanisms. With certain
underlying mechanisms, per-message protection facilities (data origin
authentication, data integrity, and data confidentiality) can also be
provided. This work is represented in a pair of RFCs: RFC-1508 (GSS-API)
and RFC-1509 (concrete bindings realizing the GSS-API for the C
language).",
URL="http://www.rfc-editor.org/rfc/rfc1511.txt"
}

@TECHREPORT{rfc1512,
AUTHOR="J. D. Case and A. Rijsinghani",
TITLE="{FDDI} Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1512,
PAGES=51,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing 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.",
URL="http://www.rfc-editor.org/rfc/rfc1512.txt"
}

@TECHREPORT{rfc1513,
AUTHOR="S. Waldbusser",
TITLE="Token Ring Extensions to the Remote Network Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1513,
PAGES=55,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="This memo defines extensions to the Remote Network Monitoring
MIB for managing 802.5 Token Ring networks. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1513.txt"
}

@TECHREPORT{rfc1514,
AUTHOR="P. Grillo and S. Waldbusser",
TITLE="Host Resources {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1514,
PAGES=33,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1514.txt"
}

@TECHREPORT{rfc1515,
AUTHOR="D. McMaster and K. McCloghrie and S. D. Roberts",
TITLE="Definitions of Managed Objects for {IEEE} {802.3} Medium Attachment Units
{(MAUs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1515,
PAGES=25,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="This document defines a portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing IEEE 802.3
Medium Attachment Units (MAUs).",
URL="http://www.rfc-editor.org/rfc/rfc1515.txt"
}

@TECHREPORT{rfc1516,
AUTHOR="D. McMaster and K. McCloghrie",
TITLE="Definitions of Managed Objects for {IEEE} {802.3} Repeater Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1516,
PAGES=40,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT={This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing IEEE 802.3 10
Mb/second baseband repeaters, sometimes referred to as {"}hubs.{"}},
URL="http://www.rfc-editor.org/rfc/rfc1516.txt"
}

@TECHREPORT{rfc1517,
AUTHOR="  and R. Hinden",
TITLE="Applicability Statement for the Implementation of Classless {Inter-Domain}
Routing {(CIDR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1517,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="Classless Inter-Domain Routing (CIDR) defines a mechanism to
slow the growth of routing tables and reduce the need to allocate new IP
network numbers.",
URL="http://www.rfc-editor.org/rfc/rfc1517.txt"
}

@TECHREPORT{rfc1518,
AUTHOR="Y. Rekhter and T. Li",
TITLE="An Architecture for {IP} Address Allocation with {CIDR}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1518,
PAGES=27,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="This paper provides an architecture and a plan for allocating
IP addresses in the Internet. This architecture and the plan are
intended to play an important role in steering the Internet towards the
Address Assignment and Aggregating Strategy outlined in RFC XXX. The IP
address space is a scarce shared resource that must be managed for the
good of the community. The managers of this resource are acting as its
custodians. They have a responsibility to the community to manage it for
the common good.",
URL="http://www.rfc-editor.org/rfc/rfc1518.txt"
}

@TECHREPORT{rfc1519,
AUTHOR="V. Fuller and T. Li and J. Yu and K. Varadhan",
TITLE="Classless {Inter-Domain} Routing {(CIDR):} an Address Assignment and
Aggregation Strategy",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1519,
PAGES=24,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1519.txt"
}

@TECHREPORT{rfc1520,
AUTHOR="Y. Rekhter and C. Topolcic",
TITLE="Exchanging Routing Information Across Provider Boundaries in the {CIDR}
Environment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1520,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT={Classless Inter-Domain Routing (CIDR) has been adopted as a
solution to the scaling problem in the Internet. The overall CIDR
architecture is described in RFC XXX. The architecture for IP address
assignment with CIDR is covered in RFC XXX and RFC XXX. The inter-domain
routing protocols that are capable of supporting CIDR are covered in RFC
XXX. The purpose of this document is twofold. First, it describes
various alternatives for exchanging inter-domain routing information
across domain boundaries, where one of the peering domain is
CIDR-capable and another is not. Second, it addresses the implications
of running CIDR-capable inter-domain routing protocols (e.g., BGP-4,
IDRP) on intra-domain routing. This document is not intended to cover
all the cases (either real or imaginable). Rather, it focuses on what
are viewed to be the most common cases. We expect that individual
service providers will use this document as guidelines in establishing
their specific operational plans for the transition to CIDR. The
concepts of {"}network service provider{"} and {"}network service
subscriber{"}
were introduced in RFC XXX. For the sake of brevity, we will use the
term {"}provider{"} or {"}service provider{"} here to mean either
{"}network
service provider{"} or {"}network service subscriber{"}, since for the most
part, the distinction is not important to this discussion. Furthermore,
we use the same terms to refer to the network and to the organization
that operates the network. We feel that the context makes it amply clear
whether we are talking about hardware or people, and defining different
terms would only make this paper harder to read.},
URL="http://www.rfc-editor.org/rfc/rfc1520.txt"
}

@TECHREPORT{rfc1521,
AUTHOR="N. Borenstein and N. Freed",
TITLE="{MIME} (Multipurpose Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet Message Bodies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1521,
PAGES=81,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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. 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. 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 (RFC 1522). This
document is a revision of RFC 1341. Significant differences from RFC
1341 are summarized in Appendix H.",
URL="http://www.rfc-editor.org/rfc/rfc1521.txt"
}

@TECHREPORT{rfc1522,
AUTHOR="K. Moore",
TITLE="{MIME} (Multipurpose Internet Mail Extensions) Part Two: Message Header
Extensions for {Non-ASCII} Text",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1522,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1522.txt"
}

@TECHREPORT{rfc1523,
AUTHOR="N. Borenstein",
TITLE="The text/enriched {MIME} Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1523,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT={MIME (RFC-1341, RFC-1521) 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.},
URL="http://www.rfc-editor.org/rfc/rfc1523.txt"
}

@TECHREPORT{rfc1524,
AUTHOR="N. Borenstein",
TITLE="A User Agent Configuration Mechanism For Multimedia Mail Format Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1524,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1524.txt"
}

@TECHREPORT{rfc1525,
AUTHOR="E. Decker and K. McCloghrie and P. Langille and A. Rijsinghani",
TITLE="Definitions of Managed Objects for Source Routing Bridges",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1525,
PAGES=18,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular, it defines objects for managing source routing
and source routing transparent bridges. These bridges are also required
to implement relevant groups in the Bridge MIB. This MIB supersedes the
dot1dSr group of objects published in an earlier version of the Bridge
MIB, RFC 1286. Changes have primarily been made to track changes in the
IEEE 802.5M SRT Addendum to the IEEE 802.1D Standard for MAC Bridges.",
URL="http://www.rfc-editor.org/rfc/rfc1525.txt"
}

@TECHREPORT{rfc1526,
AUTHOR="D. Piscitello",
TITLE="Assignment of System Identifiers for {TUBA/CLNP} Hosts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1526,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1526.txt"
}

@TECHREPORT{rfc1527,
AUTHOR="G. Cook",
TITLE="What Should We Plan Given the Dilemma of the Network?",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1527,
PAGES=17,
DAYS=15,
MONTH=sep,
YEAR=1993,
ABSTRACT="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). 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? 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1527.txt"
}

@TECHREPORT{rfc1528,
AUTHOR="C. Malamud and M. P. Rose",
TITLE="Principles of Operation for the {TPC.INT} Subdomain: Remote Printing {--}
Technical Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1528,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="Although electronic mail is preferable as a means of
third-party communication, in some cases it may be necessary to print
information, in hard-copy form, at a remote location. The remote output
device may consist of a standard line printer, a printer with",
URL="http://www.rfc-editor.org/rfc/rfc1528.txt"
}

@TECHREPORT{rfc1529,
AUTHOR="C. Malamud and M. P. Rose",
TITLE="Principles of Operation for the {TPC.INT} Subdomain: Remote Printing {--}
Administrative Policies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1529,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="This document defines the administrative policies for the
operation of remote printer facilities within the context of the tpc.int
subdomain. The document describes different approaches to resource
recovery for remote printer server sites and includes discussions of
issues pertaining to auditing, security, and denial of access. The
technical procedures for remote printing are defined elsewhere. The
general principles of operation for the tpc.int subdomain are defined in
RFC XXX. An overview of the remote printing facility is returned when
electronic mail is sent to tpc-faq(at)town.hall.org.",
URL="http://www.rfc-editor.org/rfc/rfc1529.txt"
}

@TECHREPORT{rfc1530,
AUTHOR="C. Malamud and M. P. Rose",
TITLE="Principles of Operation for the {TPC.INT} Subdomain: General Principles and
Policy",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1530,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="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. 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. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1530.txt"
}

@TECHREPORT{rfc1531,
AUTHOR="R Droms",
TITLE="Dynamic Host Configuration Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1531,
PAGES=39,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="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, and DHCP participants can interoperate with BOOTP
participants.",
URL="http://www.rfc-editor.org/rfc/rfc1531.txt"
}

@TECHREPORT{rfc1532,
AUTHOR="W. Wimer",
TITLE="Clarifications and Extensions for the Bootstrap Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1532,
PAGES=22,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT={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. In addition, new issues have arisen since
the original specification was written. This memo also attempts to
address some of these.},
URL="http://www.rfc-editor.org/rfc/rfc1532.txt"
}

@TECHREPORT{rfc1533,
AUTHOR="S. Alexander and R. E. Droms",
TITLE="{DHCP} Options and {BOOTP} Vendor Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1533,
PAGES=30,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT={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.{"}
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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1533.txt"
}

@TECHREPORT{rfc1534,
AUTHOR="R. E. Droms",
TITLE="Interoperation Between {DHCP} and {BOOTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1534,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="DHCP provides a superset of the functions provided by BOOTP.
This document describes the interactions between DHCP and BOOTP network
participants.",
URL="http://www.rfc-editor.org/rfc/rfc1534.txt"
}

@TECHREPORT{rfc1535,
AUTHOR="E. Gavron",
TITLE="A Security Problem and Proposed Correction With Widely Deployed {DNS}
Software",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1535,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1535.txt"
}

@TECHREPORT{rfc1536,
AUTHOR="A. Kumar and J. B. Postel and C. Neuman and P. Danzig and S. Miller",
TITLE="Common {DNS} Implementation Errors and Suggested Fixes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1536,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1536.txt"
}

@TECHREPORT{rfc1537,
AUTHOR="P. Beertema",
TITLE="Common {DNS} Data File Configuration Errors",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1537,
PAGES=9,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1537.txt"
}

@TECHREPORT{rfc1538,
AUTHOR="W. Behl and B. Sterling and W. Teskey",
TITLE="Advanced {SNA/IP} : A Simple {SNA} Transport Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1538,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="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(at)mcdata.com.",
URL="http://www.rfc-editor.org/rfc/rfc1538.txt"
}

@TECHREPORT{rfc1539,
AUTHOR="G. Malkin",
TITLE="The Tao of {IETF} - A Guide for New Attendees of the Internet Engineering
Task Force",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1539,
PAGES=22,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1539.txt"
}

@TECHREPORT{rfc1543,
AUTHOR="J. B. Postel",
TITLE="Instructions to {RFC} Authors",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1543,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1993,
ABSTRACT="This Request for Comments (RFC) provides information about the
preparation of RFCs, and certain policies relating to the publication of
RFCs. The RFC series of notes covers a broad range of interests. The
core topics are the Internet and the TCP/IP protocol suite. However, any",
URL="http://www.rfc-editor.org/rfc/rfc1543.txt"
}

@TECHREPORT{rfc1544,
AUTHOR="M. P. Rose",
TITLE="The {Content-MD5} Header Field",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1544,
PAGES=3,
DAYS=15,
MONTH=nov,
YEAR=1993,
ABSTRACT="This memo specifies an optional header field, Content-MD5, for
use with MIME-conformant messages.",
URL="http://www.rfc-editor.org/rfc/rfc1544.txt"
}

@TECHREPORT{rfc1545,
AUTHOR="D. Piscitello",
TITLE="{FTP} Operation Over Big Address Records {(FOOBAR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1545,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=1993,
ABSTRACT="This paper describes a convention for specifying longer
addresses in the PORT command.",
URL="http://www.rfc-editor.org/rfc/rfc1545.txt"
}

@TECHREPORT{rfc1546,
AUTHOR="C. Partridge and T. D. Mendez and W. Milliken",
TITLE="Host Anycasting Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1546,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=1993,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1546.txt"
}

@TECHREPORT{rfc1547,
AUTHOR="D. Perkins",
TITLE="Requirements for an Internet Standard {Point-to-Point} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1547,
PAGES=21,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1547.txt"
}

@TECHREPORT{rfc1548,
AUTHOR="W. Simpson",
TITLE="The {Point-to-Point} Protocol {(PPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1548,
PAGES=53,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="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: 1. A method for encapsulating
multi-protocol datagrams. 2. A Link Control Protocol (LCP) for
establishing, configuring, and testing the data-link connection. 3. A
family of Network Control Protocols (NCPs) for establishing and
configuring different network-layer protocols. 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. 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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1548.txt"
}

@TECHREPORT{rfc1549,
EDITOR="W. Simpson",
TITLE="{PPP} in {HDLC} Framing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1549,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="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 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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1549.txt"
}

@TECHREPORT{rfc1550,
AUTHOR="S. Bradner and Allison Mankin",
TITLE="{IP:} Next Generation {(IPng)} White Paper Solicitation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1550,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="The IP: next generation (IPng) area in the IETF is soliciting
white papers on topics related to the IPng requirements and selection
criteria. All interested parties are invited to submit white papers
detailing any specific requirements that they feel an IPng must fulfill
or any factors that they feel might sway the IPng selection. An example
of the former might be a submission by a representative of a utility
company detailing the scaling and addressing features which would be
required to service future inclusion of utility meters on the network.
An example of the other case might be a paper outlining the potential
effect on IPng of some sections of the future network connectivity being
provided via wireless networks. At this time, we are not accepting white
papers that evaluate specific IPng proposals. This type of document will
be accepted after the various proposal documents are deemed to be clear
and complete.",
URL="http://www.rfc-editor.org/rfc/rfc1550.txt"
}

@TECHREPORT{rfc1551,
AUTHOR="M. Allen",
TITLE="Novell {IPX} Over Various {WAN} Media {(IPXWAN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1551,
PAGES=22,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1551.txt"
}

@TECHREPORT{rfc1552,
AUTHOR="W. Simpson",
TITLE="The {PPP} Internetworking Packet Exchange Control Protocol {(IPXCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1552,
PAGES=16,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="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. 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. This memo is the
product of the Point-to-Point Protocol Working Group of the IETF.
Comments should be submitted to the ietf- ppp(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1552.txt"
}

@TECHREPORT{rfc1553,
AUTHOR="S. Mathur and M. Lewis",
TITLE="Compressing {IPX} Headers Over {WAN} Media {(CIPX)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1553,
PAGES=23,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="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. 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(at)ucdavis.edu
mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1553.txt"
}

@TECHREPORT{rfc1554,
AUTHOR="M. Ohta and K. Handa",
TITLE="{ISO-2022-JP-2:} Multilingual Extension of {ISO-2022-JP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1554,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT={This memo describes a text encoding scheme: {"}ISO-2022-JP-2{"},
which is used experimentally for electronic mail (RFC822) and network
news (RFC1036) messages in several Japanese networks. The encoding is a
multilingual extension of {"}ISO-2022-JP{"}, the existing encoding for
Japanese (2022JP). The encoding is supported by an Emacs based
multilingual text editor: MULE. The name, {"}ISO-2022-JP-2{"}, is intended
to be used in the {"}charset{"} parameter field of MIME headers.},
URL="http://www.rfc-editor.org/rfc/rfc1554.txt"
}

@TECHREPORT{rfc1555,
AUTHOR="H. Nussbacher and Y. Bourvine",
TITLE="Hebrew Character Encoding for Internet Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1555,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="This document describes the encoding used in electronic mail
(RFC822) for transferring Hebrew. The standard devised makes use of MIME
(RFC1521) and ISO-8859-8.",
URL="http://www.rfc-editor.org/rfc/rfc1555.txt"
}

@TECHREPORT{rfc1556,
AUTHOR="H. Nussbacher",
TITLE="Handling of Bi-directional Texts in {MIME}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1556,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT={This document describes the format and syntax of the
{"}direction{"} keyword to be used with bi-directional texts in MIME.},
URL="http://www.rfc-editor.org/rfc/rfc1556.txt"
}

@TECHREPORT{rfc1557,
AUTHOR="United States Postal Service  and K. Chon and H. S. Park",
TITLE="Korean Character Encoding for Internet Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1557,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="This document describes the encoding method being used to
represent Korean characters in both header and body part of the Internet
mail messages (RFC822). This encoding method was specified in 1991, and
has since then been used. It has now widely being used in Korean IP
networks. This document also describes the name of the encoding method
which is to be used in order to match the message header and body format
of MIME. This document describes only the encoding method for plain
text. Other text subtypes, rich text and similar forms of text, are
beyond the scope of this document.",
URL="http://www.rfc-editor.org/rfc/rfc1557.txt"
}

@TECHREPORT{rfc1558,
AUTHOR="T. Howes",
TITLE="A String Representation of {LDAP} Search Filters",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1558,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1558.txt"
}

@TECHREPORT{rfc1559,
AUTHOR="J. Saperia",
TITLE="{DECnet} Phase {IV} {MIB} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1559,
PAGES=69,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="This memo defines a set of DECnet Phase IV extensions that
have been created for the Internet MIB. It reflects changes which are
the result of operational experience based on RFC 1289. When used in
conjunction with the structure of management information (STD 16, RFC
1155), the management information base for network management of
TCP/IP-based internets (STD 17, RFC 1213) and the Simple Network
Management Protocol (STD 15, 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). With the
adoption of The Simple Network Management Protocol (STD 15, RFC 1157),
the management information base for network management of TCP/IP-based
internets (STD 17, RFC 1213), and the structure of",
URL="http://www.rfc-editor.org/rfc/rfc1559.txt"
}

@TECHREPORT{rfc1560,
AUTHOR="B. M. Leiner and Y. Rekhter",
TITLE="The {MultiProtocol} Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1560,
PAGES=7,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="This document was prepared by the authors on behalf of the
Internet Architecture Board (IAB). It is offered by the IAB to stimulate
discussion. 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. 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: - maintain its focus on the TCP/IP protocol suite, - work to
select a single next-generation internet protocol and develop mechanisms
to aid in transition from the current IPv4, and - continue to explore
mechanisms to interoperate and share resources with other protocol
suites within the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1560.txt"
}

@TECHREPORT{rfc1561,
AUTHOR="D. Piscitello",
TITLE="Use of {ISO} {CLNP} in {TUBA} Environments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1561,
PAGES=25,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="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). 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.",
URL="http://www.rfc-editor.org/rfc/rfc1561.txt"
}

@TECHREPORT{rfc1562,
AUTHOR="G. Michaelson and M. Prior",
TITLE="Naming Guidelines for the {AARNet} {X.500} Directory Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1562,
PAGES=4,
DAYS=15,
MONTH=dec,
YEAR=1993,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1562.txt"
}

@TECHREPORT{rfc1563,
AUTHOR="N. Borenstein",
TITLE="The text/enriched {MIME} Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1563,
PAGES=16,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT={MIME (RFC-1341, RFC-1521) 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.},
URL="http://www.rfc-editor.org/rfc/rfc1563.txt"
}

@TECHREPORT{rfc1564,
AUTHOR="P. Barker and R. Hedberg",
TITLE="{DSA} Metrics {(OSI-DS} 34 (v3))",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1564,
PAGES=21,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="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. Please send comments to the authors or to the discussion group
<osi-ds(at)CS.UCL.AC.UK>.",
URL="http://www.rfc-editor.org/rfc/rfc1564.txt"
}

@TECHREPORT{rfc1565,
AUTHOR="S. E. Kille and N. Freed",
TITLE="Network Services Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1565,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="There are a wide range of networked applications for which it
is appropriate to provide SNMP Monitoring. This includes both TCP/IP and
OSI applications. This document defines a MIB which contains the
elements common to the monitoring of any network service application.
This information includes a table of all monitorable network service
applications, a count of the associations (connections) to each
application, and basic information about the parameters and status of
each application-related association. This MIB may be used on its own
for any application, and for most simple applications this will suffice.
This MIB is also designed to serve as a building block which can be used
in conjunction with application-specific monitoring and management. Two
examples of this are MIBs defining additional variables for monitoring a
Message Transfer Agent (MTA) service or a Directory Service Agent (DSA)
service. It is expected that further MIBs of this nature will be
specified. This MIB does not attempt to provide facilities for
management of the host or hosts the network service application runs on,
nor does it provide facilities for monitoring applications that provide
something other than a network service. Host resource and general
application monitoring is handled by the Host Resources MIB.",
URL="http://www.rfc-editor.org/rfc/rfc1565.txt"
}

@TECHREPORT{rfc1566,
AUTHOR="S. E. Kille and N. Freed",
TITLE="Mail Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1566,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, this memo extends the basic Network Services
Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It
may also be used to monitor MTA components within gateways.",
URL="http://www.rfc-editor.org/rfc/rfc1566.txt"
}

@TECHREPORT{rfc1567,
AUTHOR="G. Mansfield and S. E. Kille",
TITLE="{X.500} Directory Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1567,
PAGES=18,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1567.txt"
}

@TECHREPORT{rfc1568,
AUTHOR="A. Gwinn",
TITLE="Simple Network Paging Protocol - Version 1(b)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1568,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1568.txt"
}

@TECHREPORT{rfc1569,
AUTHOR="M. P. Rose",
TITLE="Principles of Operation for the {TPC.INT} Subdomain: Radio Paging {--}
Technical Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1569,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT={As an adjunct to the usual, two-way electronic mail service,
it is at times useful to employ a one-way text notification service,
called radio paging. This memo describes a technique for radio paging
using the Internet mail infrastructure. In particular, this memo focuses
on the case in which radio pagers are identified via the international
telephone network. The technique described by this memo, mapping
telephone numbers to domain names, is derived from the TPC.INT
subdomain. Consult RFC 1530, {"}Principles of Operation for the TPC.INT
Subdomain: General Principles and Policy{"} for overview information.},
URL="http://www.rfc-editor.org/rfc/rfc1569.txt"
}

@TECHREPORT{rfc1570,
EDITOR="W. Simpson",
TITLE="{PPP} {LCP} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1570,
PAGES=18,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="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. 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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1570.txt"
}

@TECHREPORT{rfc1571,
AUTHOR="D. Borman",
TITLE="Telnet Environment Option Interoperability Issues",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1571,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="This document describes a method for allowing implementors to
ensure that their implementation of the Environment option will be
interoperable with as many other implementations as possible, by
providing a set of heuristics that can be used to help identify which
definitions for VAR and VALUE are being used by the other side of the
connection. This memo provides information for the Internet community.
This memo does not specify an Internet standard of any kind.",
URL="http://www.rfc-editor.org/rfc/rfc1571.txt"
}

@TECHREPORT{rfc1572,
EDITOR="S. Alexander",
TITLE="Telnet Environment Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1572,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="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. This document corrects some errors in RFC XXX.",
URL="http://www.rfc-editor.org/rfc/rfc1572.txt"
}

@TECHREPORT{rfc1573,
AUTHOR="K. McCloghrie and F. Kastenholz",
TITLE="Evolution of the Interfaces Group of {MIB-II}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1573,
PAGES=55,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
Network Interfaces. This memo discusses the 'interfaces' group of
MIB-II, especially the experience gained from the definition of numerous
media-specific MIB modules for use in conjunction with the 'interfaces'
group for managing various sub-layers beneath the internetwork-layer. It
proposes clarifications to, and extensions of, the architectural issues
within the current model used for the 'interfaces' group. This memo also
includes a MIB module. As well as including new MIB definitions to
support the architectural extensions, this MIB module also re-specifies
the 'interfaces' group of MIB-II in a manner which is both compliant to
the SNMPv2 SMI and semantically-identical to the existing SNMPv1-based
definitions.",
URL="http://www.rfc-editor.org/rfc/rfc1573.txt"
}

@TECHREPORT{rfc1574,
AUTHOR="S. Hares and C. Wittbrodt",
TITLE="Essential Tools for the {OSI} Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1574,
PAGES=13,
DAYS=15,
MONTH=feb,
YEAR=1994,
ABSTRACT="This document specifies the following three necessary tools to
debug problems in the deployment and maintenance of networks using ISO
8473 (CLNP): ping or OSI Echo function; traceroute function which uses
the OSI Echo function; routing table dump function 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. To support some of the needed tools
(ping and traceroute) this memo specifies the mechanism specified in RFC
1575.",
URL="http://www.rfc-editor.org/rfc/rfc1574.txt"
}

@TECHREPORT{rfc1575,
AUTHOR="S. Hares and C. Wittbrodt",
TITLE="An Echo Function for {CLNP} {(ISO} {8473)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1575,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1575.txt"
}

@TECHREPORT{rfc1576,
AUTHOR="J. Penner",
TITLE="{TN3270} Current Practices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1576,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT="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. Information is provided to aid in the implementation of
TN3270 servers as well as client terminal emulators. The following areas
pertaining to TN3270 implementations are covered in this document: 1.
the telnet options negotiated to transition from a NVT ASCII state to a
TN3270 state ready to process incoming 3270 data stream commands 2. the
method for sending and receiving 3270 data 3. the method of handling
some special keys known as SYSREQ and ATTN using current available
telnet commands 4. the events that will transition a TN3270 session back
to an NVT session",
URL="http://www.rfc-editor.org/rfc/rfc1576.txt"
}

@TECHREPORT{rfc1577,
AUTHOR="M. Laubach",
TITLE="Classical {IP} and {ARP} over {ATM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1577,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=1994,
ABSTRACT={This memo defines an initial application of classical IP and
ARP in an Asynchronous Transfer Mode (ATM) network environment
configured as a Logical IP Subnetwork (LIS) as described in Section 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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1577.txt"
}

@TECHREPORT{rfc1578,
AUTHOR="J. Sellers",
TITLE={{FYI} on Questions and Answers - Answers to Commonly Asked {"}Primary and
Secondary School Internet User{"} Questions},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1578,
PAGES=53,
DAYS=15,
MONTH=feb,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1578.txt"
}

@TECHREPORT{rfc1579,
AUTHOR="S. M. Bellovin",
TITLE="{Firewall-Friendly} {FTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1579,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1579.txt"
}

@TECHREPORT{rfc1580,
AUTHOR="Earn Staff",
TITLE="Guide to Network Resource Tools",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1580,
PAGES=107,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="The purpose of this guide is to supply the basic information
that anyone on the network needs to try out and begin using tools. This
memo provides information for the Internet community. This memo does not
specify an Internet standard of any kind.",
URL="http://www.rfc-editor.org/rfc/rfc1580.txt"
}

@TECHREPORT{rfc1581,
AUTHOR="G. Meyer",
TITLE="Protocol Analysis for Extensions to {RIP} to Support Demand Circuits",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1581,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1994,
ABSTRACT="As required by Routing Protocol Criteria, this report
documents the key features of Routing over Demand Circuits on Wide Area
Networks - RIP and the current implementation experience.",
URL="http://www.rfc-editor.org/rfc/rfc1581.txt"
}

@TECHREPORT{rfc1582,
AUTHOR="G. Meyer",
TITLE="Extensions to {RIP} to Support Demand Circuits",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1582,
PAGES=29,
DAYS=15,
MONTH=feb,
YEAR=1994,
ABSTRACT="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. 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). 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. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1582.txt"
}

@TECHREPORT{rfc1583,
AUTHOR="J. Moy",
TITLE="{OSPF} Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1583,
PAGES=216,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="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. 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. 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. Please send comments to
ospf(at)gated.cornell.edu.",
URL="http://www.rfc-editor.org/rfc/rfc1583.txt"
}

@TECHREPORT{rfc1584,
AUTHOR="J. Moy",
TITLE="Multicast Extensions to {OSPF}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1584,
PAGES=102,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="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. 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. 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). Please send comments to
mospf(at)gated.cornell.edu.",
URL="http://www.rfc-editor.org/rfc/rfc1584.txt"
}

@TECHREPORT{rfc1585,
AUTHOR="J. Moy",
TITLE="{MOSPF:} Analysis and Experience",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1585,
PAGES=13,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT={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{"} (RFC 1264). Please send comments to mospf(at)gated.cornell.edu.},
URL="http://www.rfc-editor.org/rfc/rfc1585.txt"
}

@TECHREPORT{rfc1586,
AUTHOR="O. deSouza and M. A. Rodrigues",
TITLE="Guidelines for Running {OSPF} Over Frame Relay Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1586,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1586.txt"
}

@TECHREPORT{rfc1587,
AUTHOR="R. Coltun and V. Fuller",
TITLE="The {OSPF} {NSSA} Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1587,
PAGES=17,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1587.txt"
}

@TECHREPORT{rfc1588,
AUTHOR="J. B. Postel and C. W. Anderson",
TITLE="White Pages Meeting Report",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1588,
PAGES=35,
DAYS=15,
MONTH=feb,
YEAR=1994,
ABSTRACT="This report describes the results of a meeting held at the
November IETF (Internet Engineering Task Force) in Houston, TX, on
November 2, 1993, to discuss the future of and approaches to a white
pages directory services for the Internet. As proposed to the National
Science Foundation (NSF), USC/Information Sciences Institute (ISI)
conducted the meeting to discuss the viability of the X.500 directory as
a practical approach to providing white pages service for the Internet
in the near future and to identify and discuss any alternatives. An
electronic mail mailing list was organized and discussions were held via
email for two weeks prior to the meeting.",
URL="http://www.rfc-editor.org/rfc/rfc1588.txt"
}

@TECHREPORT{rfc1589,
AUTHOR="D. L. Mills",
TITLE="A Kernel Model for Precision Timekeeping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1589,
PAGES=37,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="This memorandum describes an engineering model which
implements a precision time-of-day function for a generic operating
system. The model is based on the principles of disciplined oscillators
and phase-lock loops (PLL) often found in the engineering literature. It
has been implemented in the Unix kernel for several workstations,
including those made by Sun Microsystems and Digital Equipment. The
model changes the way the system clock is adjusted in time and
frequency, as well as provides mechanisms to discipline its frequency to
an external precision timing source. The model incorporates a generic
system-call interface for use with the Network Time Protocol (NTP) or
similar time synchronization protocol. The NTP Version 3 daemon xntpd
operates with this model to provide synchronization limited in principle
only by the accuracy and stability of the external timing source. This
memorandum does not obsolete or update any RFC. It does not propose a
standard protocol, specification or algorithm. It is intended to provoke
comment, refinement and alternative implementations. While a working
knowledge of NTP is not required for an understanding of the design
principles or implementation of the model, it may be helpful in
understanding how the model behaves in a fully functional timekeeping
system. The architecture and design of NTP is described elsewhere, while
the current NTP Version 3 protocol specification is given in RFC-1305
and a subset of the protocol, the Simple Network Time Protocol (SNTP),
in RFC-1361. The model has been implemented in three Unix kernels for
Sun Microsystems and Digital Equipment workstations. In addition, for
the Digital machines the model provides improved precision to one
microsecond (us). Since these specific implementations involve
modifications to licensed code, they cannot be provided directly.
Inquiries should be directed to the manufacturer's representatives.
However, the engineering model for these implementations, including a",
URL="http://www.rfc-editor.org/rfc/rfc1589.txt"
}

@TECHREPORT{rfc1590,
AUTHOR="J. B. Postel",
TITLE="Media Type Registration Procedure",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1590,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT={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) protocol defined
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.},
URL="http://www.rfc-editor.org/rfc/rfc1590.txt"
}

@TECHREPORT{rfc1591,
AUTHOR="J. B. Postel",
TITLE="Domain Name System Structure and Delegation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1591,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="This memo provides some information on the structure of the
names in the Domain Name System (DNS), specifically the top-level domain
names; and on the administration of domains. The Internet Assigned
Numbers Authority (IANA) is the overall authority for the IP Addresses,
the Domain Names, and many other parameters, used in the Internet. The
day-to-day responsibility for the assignment of IP Addresses, Autonomous
System Numbers, and most top and second level Domain Names are handled
by the Internet Registry (IR) and regional registries.",
URL="http://www.rfc-editor.org/rfc/rfc1591.txt"
}

@TECHREPORT{rfc1592,
AUTHOR="B. Wijnen and G. A. Carpenter and K. Curran and A. Sehgal and G. Waters",
TITLE="Simple Network Management Protocol Distributed Protocol Interface Version
{2.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1592,
PAGES=54,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="This RFC describes version 2.0 of a protocol that
International Business Machines Corporation (IBM) has been implementing
in most of its SNMP agents to allow dynamic extension of supported MIBs.
Bell Northern Research (BNR) has also implemented a version of this
protocol in some of its SNMP agents for the same reason. The Simple
Network Management Protocol (SNMP) Distributed Protocol 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. For the author of a sub-agent, the SNMP-DPI
eliminates the need to know the details of ASN.1 or SNMP PDU (Protocol
Data Unit) encoding/decoding. Versions 1.0 and 1.1 of this protocol have
been in use within IBM",
URL="http://www.rfc-editor.org/rfc/rfc1592.txt"
}

@TECHREPORT{rfc1593,
AUTHOR="W. McKenzie and J. Cheng",
TITLE="{SNA} {APPN} Node {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1593,
PAGES=120,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="This RFC describes IBM's SNMP support for SNA Advanced
Peer-to-Peer Networking (APPN) nodes.",
URL="http://www.rfc-editor.org/rfc/rfc1593.txt"
}

@TECHREPORT{rfc1594,
AUTHOR="A. N. Marine and J. F. Reynolds and G. Malkin",
TITLE={{FYI} on Questions and Answers - Answers to Commonly asked {"}New Internet
User{"} Questions},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1594,
PAGES=44,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1594.txt"
}

@TECHREPORT{rfc1595,
AUTHOR="T. Brown and K. Tesink",
TITLE="Definitions of Managed Objects for the {SONET/SDH} Interface Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1595,
PAGES=59,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This
document is a companion document with Definitions of Managed Objects for
the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407. This memo
specifies a MIB module in a manner that is both compliant to the SNMPv2
SMI, and semantically identical to the peer SNMPv1 definitions.",
URL="http://www.rfc-editor.org/rfc/rfc1595.txt"
}

@TECHREPORT{rfc1596,
AUTHOR="Editor T. Brown",
TITLE="Definitions of Managed Objects for Frame Relay Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1596,
PAGES=46,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1596.txt"
}

@TECHREPORT{rfc1597,
AUTHOR="Y. Rekhter and B. Moskowitz and D. Karrenberg and G. de Groot",
TITLE="Address Allocation for Private Internets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1597,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="This RFC describes methods to preserve IP address space by not
allocating globally unique IP addresses to hosts private to an
enterprise while still permitting full network layer connectivity
between all hosts inside an enterprise as well as between all public
hosts of different enterprises. The authors hope, that using these
methods, significant savings can be made on allocating IP address space.
For the purposes of this memo, an enterprise is an entity autonomously
operating a network using TCP/IP and in particular determining the
addressing plan and address assignments within that network.",
URL="http://www.rfc-editor.org/rfc/rfc1597.txt"
}

@TECHREPORT{rfc1598,
AUTHOR="W. Simpson",
TITLE="{PPP} in {X.25}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1598,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="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. 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(at)merit.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1598.txt"
}

@TECHREPORT{rfc1600,
AUTHOR="Editor J. Postel",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1600,
PAGES=36,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="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. This memo is intended to be issued approximately
quarterly; please be sure the copy you are reading is current. Current
copies may be obtained from the Network Information Center (INTERNIC) or
from the Internet Assigned Numbers Authority (IANA) (see the contact
information at the end of this memo). Do not use this edition after
31-May-94. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1600.txt"
}

@TECHREPORT{rfc1601,
AUTHOR="C. Huitema",
TITLE="Charter of the Internet Architecture Board {(IAB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1601,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="This memo documents the composition, selection, roles, and
organization of the Internet Architecture Board and its subsidiary
organizations.",
URL="http://www.rfc-editor.org/rfc/rfc1601.txt"
}

@TECHREPORT{rfc1602,
AUTHOR="Internet Activities Board and  ",
TITLE="The Internet Standards Process {--} Revision 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1602,
PAGES=37,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="This document is a revision of RFC 1310, which defined the
official procedures for creating and documenting Internet Standards.
This revision (revision 2) includes the following major changes: (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. (b) Prototype status is added to the
non-standards track maturity levels (Section 2.4.1). (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.",
URL="http://www.rfc-editor.org/rfc/rfc1602.txt"
}

@TECHREPORT{rfc1603,
AUTHOR="E. Huizer and D. H. Crocker",
TITLE="{IETF} Working Group Guidelines and Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1603,
PAGES=29,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1603.txt"
}

@TECHREPORT{rfc1605,
AUTHOR="W. Shakespeare",
TITLE="{SONET} to Sonnet Translation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1605,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1994,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1605.txt"
}

@TECHREPORT{rfc1606,
AUTHOR="J. Onions",
TITLE="A Historical Perspective On The Usage Of {IP} Version 9",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1606,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1994,
ABSTRACT="This paper reviews the usages of the old IP version protocol.
It considers some of its successes and its failures.",
URL="http://www.rfc-editor.org/rfc/rfc1606.txt"
}

@TECHREPORT{rfc1607,
AUTHOR="V. G. Cerf",
TITLE="A view from the 21st century",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1607,
PAGES=14,
DAYS=15,
MONTH=apr,
YEAR=1994,
ABSTRACT="This document is a composition of letters discussing a
possible future.",
URL="http://www.rfc-editor.org/rfc/rfc1607.txt"
}

@TECHREPORT{rfc1608,
AUTHOR="T. Johannsen and G. Mansfield and M. Kosters and S. Sataluri",
TITLE="Representing {IP} Information in the {X.500} Directory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1608,
PAGES=20,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1608.txt"
}

@TECHREPORT{rfc1609,
AUTHOR="G. Mansfield and T. Johannsen and M. Knopper",
TITLE="Charting Networks in the {X.500} Directory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1609,
PAGES=15,
DAYS=15,
MONTH=mar,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1609.txt"
}

@TECHREPORT{rfc1611,
AUTHOR="R. Austein and J. Saperia",
TITLE="{DNS} Server {MIB} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1611,
PAGES=30,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes a set of extensions which
instrument DNS name server functions. This memo was produced by the DNS
working group. With the adoption of the Internet-standard Network
Management Framework, and with a large number of vendor implementations
of these standards in commercially available products, it became
possible to provide a higher level of effective network management in
TCP/IP-based internets than was previously available. With the growth in
the use of these standards, it has become possible to consider the
management of other elements of the infrastructure beyond the basic
TCP/IP protocols. A key element of",
URL="http://www.rfc-editor.org/rfc/rfc1611.txt"
}

@TECHREPORT{rfc1612,
AUTHOR="R. Austein and J. Saperia",
TITLE="{DNS} Resolver {MIB} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1612,
PAGES=32,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes a set of extensions which
instrument DNS resolver functions. This memo was produced by the DNS
working group. With the adoption of the Internet-standard Network
Management Framework, and with a large number of vendor implementations
of these standards in commercially available products, it became
possible to provide a higher level of effective network management in
TCP/IP-based internets than was previously available. With the growth in
the use of these standards, it has become possible to consider the
management of other elements of the infrastructure beyond the basic
TCP/IP protocols. A key element of",
URL="http://www.rfc-editor.org/rfc/rfc1612.txt"
}

@TECHREPORT{rfc1613,
AUTHOR="J. Forster and G. Satz and G. Glick and R. Day",
TITLE="cisco Systems {X.25} over {TCP} {(XOT)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1613,
PAGES=13,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="It is sometimes desirable to transport X.25 over IP internets.
The X.25 Packet Level requires a reliable link level below it and
normally uses LAPB. This memo documents a method of sending X.25 packets
over IP internets by encapsulating the X.25 Packet Level in TCP packets.
TCP provides a reliable byte stream. X.25 requires that the layer below
it provide message semantics, in particular the boundary between
packets. To provide this, a small (4-byte) XOT header is used between
TCP and X.25. The primary content of this header is a",
URL="http://www.rfc-editor.org/rfc/rfc1613.txt"
}

@TECHREPORT{rfc1614,
AUTHOR="C. Adie",
TITLE="Network Access to Multimedia Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1614,
PAGES=79,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="This report summarises the requirements of research and
academic network users for network access to multimedia information. It
does this by investigating some of the projects planned or currently
underway in the community. Existing information systems such as Gopher,
WAIS and World-Wide Web are examined from the point of view of
multimedia support, and some interesting hypermedia systems emerging
from the research community are also studied. Relevant existing and
developing standards in this area are discussed. The report identifies
the gaps between the capabilities of currentlydeployed systems and the
user requirements, and proposes further work centred on the World-Wide
Web system to rectify this. The report is in some places very detailed,
so it is preceded by an extended summary, which outlines the findings of
the report.",
URL="http://www.rfc-editor.org/rfc/rfc1614.txt"
}

@TECHREPORT{rfc1615,
AUTHOR="J. Houttuin and J. Craigie",
TITLE="Migrating from {X.400(84)} to {X.400(88)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1615,
PAGES=17,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1615.txt"
}

@TECHREPORT{rfc1616,
EDITOR="  and E. Huizer and J. Romaguera",
TITLE="{X.400(1988)} for the Academic and Research Community in Europe",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1616,
PAGES=44,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="The European research and development community, as
represented by the member research networks of RARE, has lead the
deployment within the global R\&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\&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\&D community but within commercial service
providers and organisations as well. 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\&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\&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. The Commission of European Communities (CEC) VALUE
subprogram II has been established to support initiatives relating to
the development and adaptation of R\&D networks in member states. Amongst
other",
URL="http://www.rfc-editor.org/rfc/rfc1616.txt"
}

@TECHREPORT{rfc1617,
AUTHOR="P. Barker and S. E. Kille and T. Lenggenhager",
TITLE="Naming and Structuring Guidelines for {X.500} Directory Pilots",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1617,
PAGES=28,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1617.txt"
}

@TECHREPORT{rfc1618,
AUTHOR="W. Simpson",
TITLE="{PPP} over {ISDN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1618,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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. 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(at)merit.edu
mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1618.txt"
}

@TECHREPORT{rfc1619,
AUTHOR="W. Simpson",
TITLE="{PPP} over {SONET/SDH}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1619,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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. 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(at)merit.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1619.txt"
}

@TECHREPORT{rfc1620,
AUTHOR="B. Braden and J. B. Postel and Y. Rekhter",
TITLE="Internet Architecture Extensions for Shared Media",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1620,
PAGES=19,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1620.txt"
}

@TECHREPORT{rfc1621,
AUTHOR="P. Francis",
TITLE="Pip Near-term Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1621,
PAGES=51,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1621.txt"
}

@TECHREPORT{rfc1622,
AUTHOR="P. Francis",
TITLE="Pip Header Processing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1622,
PAGES=16,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1622.txt"
}

@TECHREPORT{rfc1623,
AUTHOR="F. Kastenholz",
TITLE="Definitions of Managed Objects for the Ethernet-like Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1623,
PAGES=19,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing ethernet-like
objects. This memo also includes a MIB module. This MIB module corrects
minor errors in the earlier version of this MIB: RFC 1398.",
URL="http://www.rfc-editor.org/rfc/rfc1623.txt"
}

@TECHREPORT{rfc1624,
EDITOR="A. Rijsinghani",
TITLE="Computation of the Internet Checksum via Incremental Update",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1624,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="This memo describes an updated technique for incremental
computation of the standard Internet checksum. It updates the method
described in RFC 1141.",
URL="http://www.rfc-editor.org/rfc/rfc1624.txt"
}

@TECHREPORT{rfc1625,
AUTHOR="M. St. Pierre and J. Fullton and K. Gamiel and J. Goldman and B. Kahle and
J. Kunze and H. Morris and F. Schiettecatte",
TITLE="{WAIS} over {Z39.50-1988}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1625,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1994,
ABSTRACT="The network publishing system, Wide Area Information Servers
(WAIS), is designed to help users find information over a computer
network. The principles guiding WAIS development are: 1. A wide-area
networked-based information system for searching, browsing, and
publishing. 2. Based on standards. 3. Easy to use. 4. Flexible and
growth oriented. From this basis, a large group of developers,
publishers, standards bodies, libraries, government agencies, schools,
and users have been helping further the WAIS system. The WAIS software
architecture has four main components: the client, the server, the
database, and the protocol. The WAIS client is a user-interface program
that sends requests for information to local or remote servers. Clients
are available for most popular desktop environments. The WAIS server is
a program that services client",
URL="http://www.rfc-editor.org/rfc/rfc1625.txt"
}

@TECHREPORT{rfc1626,
AUTHOR="R. Atkinson",
TITLE="Default {IP} {MTU} for use over {ATM} {AAL5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1626,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="There are a number of good reasons to have a reasonably large
default MTU value for IP over ATM AAL5. This paper presents the default
IP MIU for use over ATM AAL5.",
URL="http://www.rfc-editor.org/rfc/rfc1626.txt"
}

@TECHREPORT{rfc1627,
AUTHOR="E. Lear and E. Fair and D. H. Crocker and T. Kessler",
TITLE="Network 10 Considered Harmful (Some Practices Shouldn't be Codified)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1627,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="Re-use of Internet addresses for private IP networks is the
topic of the recent RFC 1597. It reserves a set of IP network numbers,
for (re-)use by any number of organizations, so long as those networks
are not routed outside any single, private IP network. RFC 1597 departs
from the basic architectural rule that IP addresses must be globally
unique, and it does so without having had the benefit of the usual,
public review and approval by the IETF or IAB. This document restates
the arguments for maintaining a unique address space. Concerns for
Internet architecture and operations, as well as IETF procedure, are
explored.",
URL="http://www.rfc-editor.org/rfc/rfc1627.txt"
}

@TECHREPORT{rfc1628,
EDITOR="J. D. Case",
TITLE="{UPS} Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1628,
PAGES=45,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing
uninterruptible power supply (UPS) systems.",
URL="http://www.rfc-editor.org/rfc/rfc1628.txt"
}

@TECHREPORT{rfc1629,
AUTHOR="R. Colella and R. Callon and E. Gardner and Y. Rekhter",
TITLE="Guidelines for {OSI} {NSAP} Allocation in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1629,
PAGES=52,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1629.txt"
}

@TECHREPORT{rfc1630,
AUTHOR="T. Berners-Lee",
TITLE="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",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1630,
PAGES=28,
DAYS=15,
MONTH=jun,
YEAR=1994,
ABSTRACT="This document defines the syntax used by the World-Wide Web
initiative to encode the names and addresses of objects on the Internet.
The web is considered to include objects accessed using an extendable
number of protocols, existing, invented for the web itself, or to be
invented in the future. Access instructions for an individual object
under a given protocol are encoded into forms of address string. Other
protocols allow the use of object names of various forms. In order to
abstract the idea of a generic object, the web needs the concepts of the
universal set of objects, and of the universal set of names or addresses
of objects. A Universal Resource Identifier (URI) is a member of this
universal set of names in registered name spaces and addresses referring
to registered protocols or name spaces. A Uniform Resource Locator
(URL), defined elsewhere, is a form of URI which expresses an address
which maps onto an access algorithm using network protocols. Existing
URI schemes which correspond to the (still mutating) concept of IETF
URLs are listed here. The Uniform Resource Name (URN) debate attempts to
define a name space (and presumably resolution protocols) for persistent
object names. This area is not addressed by this document, which is
written in order to document existing practice and provide a reference
point for URL and URN discussions.",
URL="http://www.rfc-editor.org/rfc/rfc1630.txt"
}

@TECHREPORT{rfc1631,
AUTHOR="K. Egevang and P. Francis",
TITLE="The {IP} Network Address Translator {(NAT)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1631,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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.
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.",
URL="http://www.rfc-editor.org/rfc/rfc1631.txt"
}

@TECHREPORT{rfc1632,
EDITOR="A. Getchell and S. Sataluri",
TITLE="A Revised Catalog of Available {X.500} Implementations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1632,
PAGES=94,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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. This
document contains detailed description of twenty six (26) X.500
implementations - DSAs, DUAs, and DUA interfaces.",
URL="http://www.rfc-editor.org/rfc/rfc1632.txt"
}

@TECHREPORT{rfc1633,
AUTHOR="R. Braden and D. D. Clark and S. Shenker",
TITLE="Integrated Services in the Internet Architecture: an Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1633,
PAGES=33,
DAYS=15,
MONTH=jun,
YEAR=1994,
ABSTRACT="This memo discusses a proposed extension to the Internet
architecture and protocols to provide integrated services, i.e., to
support real- time as well as the current non-real-time service of IP.
This extension is necessary to meet the growing need for real-time
service for a variety of new applications, including teleconferencing,
remote seminars, telescience, and distributed simulation. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1633.txt"
}

@TECHREPORT{rfc1634,
AUTHOR="M. Allen",
TITLE="Novell {IPX} Over Various {WAN} Media {(IPXWAN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1634,
PAGES=23,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1634.txt"
}

@TECHREPORT{rfc1635,
AUTHOR="P. Deutsch and A. Emtage and A. N. Marine",
TITLE="How to Use Anonymous {FTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1635,
PAGES=13,
DAYS=15,
MONTH=may,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1635.txt"
}

@TECHREPORT{rfc1636,
AUTHOR="R. Braden and D. D. Clark and S. D. Crocker and C. Huitema",
TITLE="Report of {IAB} Workshop on Security in the Internet Architecture -
February {8-10,} 1994",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1636,
PAGES=52,
DAYS=15,
MONTH=jun,
YEAR=1994,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1636.txt"
}

@TECHREPORT{rfc1637,
AUTHOR="B. Manning and R. Colella",
TITLE="{DNS} {NSAP} Resource Records",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1637,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=1994,
ABSTRACT="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. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1637.txt"
}

@TECHREPORT{rfc1638,
AUTHOR="F. Baker and R. Bowen",
TITLE="{PPP} Bridging Control Protocol {(BCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1638,
PAGES=28,
DAYS=15,
MONTH=jun,
YEAR=1994,
ABSTRACT="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. This document defines the Network Control
Protocol for establishing and configuring Remote Bridging for PPP links.",
URL="http://www.rfc-editor.org/rfc/rfc1638.txt"
}

@TECHREPORT{rfc1639,
AUTHOR="D. Piscitello",
TITLE="{FTP} Operation Over Big Address Records {(FOOBAR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1639,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=1994,
ABSTRACT="This paper describes a convention for specifying address
families other than the default Internet address family in FTP commands
and replies.",
URL="http://www.rfc-editor.org/rfc/rfc1639.txt"
}

@TECHREPORT{rfc1640,
AUTHOR="S. D. Crocker",
TITLE="The Process for Organization of Internet Standards Working Group {(POISED)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1640,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1640.txt"
}

@TECHREPORT{rfc1641,
AUTHOR="D. Goldsmith and M. Davis",
TITLE="Using Unicode with {MIME}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1641,
PAGES=6,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="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.
This document specifies the usage of Unicode within MIME.",
URL="http://www.rfc-editor.org/rfc/rfc1641.txt"
}

@TECHREPORT{rfc1642,
AUTHOR="D. Goldsmith and M. Davis",
TITLE="{UTF-7} - A {Mail-Safe} Transformation Format of Unicode",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1642,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT={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.
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{"}.},
URL="http://www.rfc-editor.org/rfc/rfc1642.txt"
}

@TECHREPORT{rfc1644,
AUTHOR="R. Braden",
TITLE="{T/TCP} {--} {TCP} Extensions for Transactions Functional Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1644,
PAGES=38,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1644.txt"
}

@TECHREPORT{rfc1645,
AUTHOR="A. Gwinn",
TITLE="Simple Network Paging Protocol - Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1645,
PAGES=15,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1645.txt"
}

@TECHREPORT{rfc1646,
AUTHOR="C. Graves and T. Butts and M. Angel",
TITLE="{TN3270} Extensions for {LUname} and Printer Selection",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1646,
PAGES=13,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="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(at)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.",
URL="http://www.rfc-editor.org/rfc/rfc1646.txt"
}

@TECHREPORT{rfc1647,
AUTHOR="B. Kelly",
TITLE="{TN3270} Enhancements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1647,
PAGES=34,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1647.txt"
}

@TECHREPORT{rfc1648,
AUTHOR="A. Cargille",
TITLE="Postmaster Convention for {X.400} Operations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1648,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT={Both STD 11, RFC 822 and 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.},
URL="http://www.rfc-editor.org/rfc/rfc1648.txt"
}

@TECHREPORT{rfc1649,
AUTHOR="R. A. Hagens and A. Hansen",
TITLE="Operational Requirements for {X.400} Management Domains in the {GO-MHS}
Community",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1649,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="There are several large, operational X.400 services currently
deployed. Many of the organizations in these services are connected to
the Internet. A number of other Internet-connected organizations are
beginning to operate internal X.400 services (for example, U.S.
government organizations following U.S. GOSIP). The motivation for this
document is to foster a Global Open Message Handling System (GO-MHS)
Community that has full interoperability with the existing E-mail
service based on RFC-822 (STD-11). The goal of this document is to unite
regionally operated X.400 services on the various continents into one
GO-MHS Community (as seen from an end-user's point of view). Examples of
such regional services are the COSINE MHS Service in Europe and the
XNREN service in the U.S. A successful GO-MHS Community is dependent on
decisions at both the national and international level. National X.400
service providers are responsible for the implementation of the minimum
requirements defined in this document. In addition to these minimum
requirements, national requirements may be defined by each national
service provider. This document refers to other documents which are
published as RFCs. This document handles issues concerning X.400 1984
and X.400 1988 to 1984 downgrading. Issues concerning pure X.400 1988
are left for further study.",
URL="http://www.rfc-editor.org/rfc/rfc1649.txt"
}

@TECHREPORT{rfc1650,
AUTHOR="F. Kastenholz",
TITLE="Definitions of Managed Objects for the Ethernet-like Interface Types using
{SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1650,
PAGES=20,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing ethernet-like
objects. This memo also includes a MIB module. This MIB module corrects
minor errors in the earlier version of this MIB: RFC 1398 and also
re-specifies that MIB in a manner which is both compliant to the SNMPv2
SMI and semantically-identical to the existing SNMPv1-based definitions.",
URL="http://www.rfc-editor.org/rfc/rfc1650.txt"
}

@TECHREPORT{rfc1651,
AUTHOR="J. Klensin and N. Freed and M. P. Rose and E. Stefferud and D. H. Crocker",
TITLE="{SMTP} Service Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1651,
PAGES=11,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1651.txt"
}

@TECHREPORT{rfc1652,
AUTHOR="J. Klensin and N. Freed and M. P. Rose and E. Stefferud and D. H. Crocker",
TITLE="{SMTP} Service Extension for {8bit-MIMEtransport}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1652,
PAGES=6,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1652.txt"
}

@TECHREPORT{rfc1653,
AUTHOR="J. Klensin and N. Freed and K. Moore",
TITLE="{SMTP} Service Extension for Message Size Declaration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1653,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1653.txt"
}

@TECHREPORT{rfc1654,
EDITOR="Y. Rekhter and T. Li",
TITLE="A Border Gateway Protocol 4 {(BGP-4)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1654,
PAGES=56,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="This document defines an inter-autonomous system routing
protocol for the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1654.txt"
}

@TECHREPORT{rfc1655,
EDITOR="Y. Rekhter and P. Gross",
TITLE="Application of the Border Gateway Protocol in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1655,
PAGES=19,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT={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. Information about the progress of BGP can be
monitored and/or reported on the BGP mailing list (bgp(at)ans.net).},
URL="http://www.rfc-editor.org/rfc/rfc1655.txt"
}

@TECHREPORT{rfc1656,
AUTHOR="P. Traina",
TITLE="{BGP-4} Protocol Document Roadmap and Implementation Experience",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1656,
PAGES=4,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT={Border Gateway Protocol v4 (BGP-4) is an inter-Autonomous
System routing protocol. It is built on experience gained with BGP as
defined in RFC-1267 and BGP usage in the connected Internet as described
in RFC-1268. The primary function of a BGP speaking system is to
exchange network reachability information with other BGP systems. This
network reachability information includes information on the list of
Autonomous Systems (ASs) that reachability information traverses. This
information is sufficient to construct a graph of AS connectivity from
which routing loops may be pruned and some policy decisions at the AS
level may be enforced. BGP-4 provides a new set of mechanisms for
supporting classless inter-domain routing. These mechanisms include
support for advertising an IP prefix and eliminates the concept of
network {"}class{"} within BGP. BGP-4 also introduces mechanisms which
allow
aggregation of routes, including aggregation of AS paths. These changes
provide support for the proposed supernetting scheme. The management
information base has been defined and security considerations are
discussed in the protocol definition document.},
URL="http://www.rfc-editor.org/rfc/rfc1656.txt"
}

@TECHREPORT{rfc1657,
AUTHOR="S. Willis and J. W. Burruss",
TITLE="Definitions of Managed Objects for the Fourth Version of the Border Gateway
Protocol {(BGP-4)} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1657,
MONTH=jul,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
the Border Gateway Protocol Version 4 or lower.",
URL="http://www.rfc-editor.org/rfc/rfc1657.txt"
}

@TECHREPORT{rfc1658,
AUTHOR="B. Stewart",
TITLE="Definitions of Managed Objects for Character Stream Devices using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1658,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="This memo defines an extension to the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for the management of
character stream devices.",
URL="http://www.rfc-editor.org/rfc/rfc1658.txt"
}

@TECHREPORT{rfc1659,
AUTHOR="B. Stewart",
TITLE="Definitions of Managed Objects for {RS-232-like} Hardware Devices using
{SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1659,
PAGES=21,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="This memo defines an extension to the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for the management of
RS-232-like devices.",
URL="http://www.rfc-editor.org/rfc/rfc1659.txt"
}

@TECHREPORT{rfc1660,
AUTHOR="B. Stewart",
TITLE="Definitions of Managed Objects for Parallel-printer-like Hardware Devices
using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1660,
PAGES=10,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="This memo defines an extension to the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for the management of
Parallel-printer-like devices.",
URL="http://www.rfc-editor.org/rfc/rfc1660.txt"
}

@TECHREPORT{rfc1661,
EDITOR="W. Simpson",
TITLE="The {Point-to-Point} Protocol {(PPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1661,
PAGES=52,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="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: 1. A method for encapsulating
multi-protocol datagrams. 2. A Link Control Protocol (LCP) for
establishing, configuring, and testing the data-link connection. 3. A
family of Network Control Protocols (NCPs) for establishing and
configuring different network-layer protocols. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1661.txt"
}

@TECHREPORT{rfc1662,
EDITOR="W. Simpson",
TITLE="{PPP} in {HDLC-like} Framing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1662,
PAGES=25,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="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 HDLC-like framing for PPP
encapsulated packets.",
URL="http://www.rfc-editor.org/rfc/rfc1662.txt"
}

@TECHREPORT{rfc1663,
AUTHOR="D. Rand",
TITLE="{PPP} Reliable Transmission",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1663,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links.
This document defines a method for negotiating and using Numbered- Mode,
as defined by ISO 7776, to provide a reliable serial link. 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(at)ucdavis.edu mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1663.txt"
}

@TECHREPORT{rfc1664,
AUTHOR="C. Allocchio and A. Bonito and B. Cole and S. Giordano and R. A. Hagens",
TITLE="Using the Internet {DNS} to Distribute {RFC1327} Mail Address Mapping
Tables",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1664,
PAGES=23,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1664.txt"
}

@TECHREPORT{rfc1665,
AUTHOR="Z. Kielczewski and D. Kostick and K. Shih",
EDITOR="Z. Kielczewski and D. Kostick and K. Shih",
TITLE="Definitions of Managed Objects for {SNA} {NAUs} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1665,
PAGES=67,
DAYS=15,
MONTH=jul,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing the
configuration, monitoring and control of Physical Units (PUs) and
Logical Units (LUs) in an SNA environment. PUs and LUs are two types of
Network Addressable Units (NAUs) in the logical structure of an SNA
network. NAUs are the origination or destination points for SNA data
streams. This memo identifies managed objects for PU Type 1.0, 2.0 and
Type 2.1 and LU Type 0, 1, 2, 3, 4, 7. The generic objects defined here
can also be used to manage LU 6.2 and any LU-LU session. The SNA terms
and overall architecture are documented elsewhere.",
URL="http://www.rfc-editor.org/rfc/rfc1665.txt"
}

@TECHREPORT{rfc1667,
AUTHOR="S. Symington and D. C. Wood and M. Pullen",
TITLE="Modeling and Simulation Requirements for {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1667,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1667.txt"
}

@TECHREPORT{rfc1668,
AUTHOR="D. Estrin and T. Li and Y. Rekhter",
TITLE="Unified Routing Requirements for {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1668,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1668.txt"
}

@TECHREPORT{rfc1669,
AUTHOR="J. Curran",
TITLE="Market Viability as a {IPng} Criteria",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1669,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1669.txt"
}

@TECHREPORT{rfc1670,
AUTHOR="D. Heagerty",
TITLE="Input to {IPng} Engineering Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1670,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1670.txt"
}

@TECHREPORT{rfc1671,
AUTHOR="B. E. Carpenter",
TITLE="{IPng} White Paper on Transition and Other Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1671,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1671.txt"
}

@TECHREPORT{rfc1672,
AUTHOR="Nevil Brownlee",
TITLE="Accounting Requirements for {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1672,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1672.txt"
}

@TECHREPORT{rfc1673,
AUTHOR="R. Skelton",
TITLE="Electric Power Research Institute Comments on {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1673,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1673.txt"
}

@TECHREPORT{rfc1674,
AUTHOR="M. C. Taylor",
TITLE="A Cellular Industry View of {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1674,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1674.txt"
}

@TECHREPORT{rfc1675,
AUTHOR="S. M. Bellovin",
TITLE="Security Concerns for {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1675,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1675.txt"
}

@TECHREPORT{rfc1676,
AUTHOR="A. Ghiselli and D. Salomoni and C. Vistoli",
TITLE="{INFN} Requirements for an {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1676,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1676.txt"
}

@TECHREPORT{rfc1677,
AUTHOR="B. Adamson",
TITLE="Tactical Radio Frequency Communication Requirements for {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1677,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1677.txt"
}

@TECHREPORT{rfc1678,
AUTHOR="E. Britton and J. Tavs",
TITLE="{IPng} Requirements of Large Corporate Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1678,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)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.",
URL="http://www.rfc-editor.org/rfc/rfc1678.txt"
}

@TECHREPORT{rfc1679,
AUTHOR="D. H. Green and P. Irey and D. Marlow and K. O'Donoghue",
TITLE="{HPN} Working Group Input to the {IPng} Requirements Solicitation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1679,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1679.txt"
}

@TECHREPORT{rfc1680,
AUTHOR="C. Brazdziunas",
TITLE="{IPng} Support for {ATM} Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1680,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1680.txt"
}

@TECHREPORT{rfc1681,
AUTHOR="S. M. Bellovin",
TITLE="On Many Addresses per Host",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1681,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1681.txt"
}

@TECHREPORT{rfc1682,
AUTHOR="J. Bound",
TITLE="{IPng} {BSD} Host Implementation Analysis",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1682,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1682.txt"
}

@TECHREPORT{rfc1683,
AUTHOR="R. N. Clark and M. Ammar and Ken Calvert",
TITLE="Multiprotocol Interoperability In {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1683,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1683.txt"
}

@TECHREPORT{rfc1684,
AUTHOR="P. Jurg",
TITLE="Introduction to White Pages Services based on {X.500}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1684,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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. 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.
In addition a short overview of the experience gained from the Paradise
X.500 pilot is given. References to more detailed information are
included. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1684.txt"
}

@TECHREPORT{rfc1685,
AUTHOR="H. Alvestrand",
TITLE="Writing {X.400} {O/R} Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1685,
PAGES=11,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="There is a need for human beings who use X.400 systems to be
able to write down O/R names in a uniform way. There has been a
preexisting recommendation on how to write O/R names for human
consumption in the RARE community. Now that the ISO/ITU has adopted a
recommendation on how to do this, RARE needs to update its
recommendation on writing O/R names to take this standard into account.",
URL="http://www.rfc-editor.org/rfc/rfc1685.txt"
}

@TECHREPORT{rfc1686,
AUTHOR="M. P. Vecchi",
TITLE="{IPng} Requirements: A Cable Television Industry Viewpoint",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1686,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1686.txt"
}

@TECHREPORT{rfc1687,
AUTHOR="E. Fleischman",
TITLE="A Large Corporate User's View of {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1687,
PAGES=13,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list.",
URL="http://www.rfc-editor.org/rfc/rfc1687.txt"
}

@TECHREPORT{rfc1688,
AUTHOR="W. Simpson",
TITLE="{IPng} Mobility Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1688,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list. This RFC specifies criteria
related to mobility for consideration in design and selection of the
Next Generation of IP.",
URL="http://www.rfc-editor.org/rfc/rfc1688.txt"
}

@TECHREPORT{rfc1689,
EDITOR="J. Foster",
TITLE="A Status Report on Networked Information Retrieval: Tools and Groups",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1689,
PAGES=226,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1689.txt"
}

@TECHREPORT{rfc1690,
AUTHOR="G. Huston",
TITLE="Introducing the Internet Engineering and Planning Group {(IEPG)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1690,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1690.txt"
}

@TECHREPORT{rfc1691,
AUTHOR="W. M. Turner",
TITLE="The Document Architecture for the Cornell Digital Library",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1691,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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. Two unique features of this architecture are the
ability to generate reference documents and the ability to create
multiple views of a document.",
URL="http://www.rfc-editor.org/rfc/rfc1691.txt"
}

@TECHREPORT{rfc1692,
AUTHOR="P. Cameron and D. H. Crocker and D. Cohen and J. B. Postel",
TITLE="Transport Multiplexing Protocol {(TMux)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1692,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1692.txt"
}

@TECHREPORT{rfc1693,
AUTHOR="T. Connolly and P. D. Amer and P. Conrad",
TITLE="An Extension to {TCP} : Partial Order Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1693,
PAGES=36,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1693.txt"
}

@TECHREPORT{rfc1694,
EDITOR="T. Brown and K. Tesink",
TITLE="Definitions of Managed Objects for {SMDS} Interfaces using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1694,
PAGES=35,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing objects for
SMDS access interfaces. This includes the following access protocols:
SIP, SIP/DXI, SIP/FR, SIP/ATM. 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. This
memo also assumes application of the MIB II Interfaces group.",
URL="http://www.rfc-editor.org/rfc/rfc1694.txt"
}

@TECHREPORT{rfc1695,
EDITOR="M. Ahmed and K. Tesink",
TITLE="Definitions of Managed Objects for {ATM} Management Version {8.0} using
{SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1695,
PAGES=73,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing
ATM-based interfaces, devices, networks and services. This memo
specifies a MIB module in a manner that is both compliant to the SNMPv2
SMI, and semantically identical to the peer SNMPv1 definitions.",
URL="http://www.rfc-editor.org/rfc/rfc1695.txt"
}

@TECHREPORT{rfc1696,
AUTHOR="J. A. Barnes and L. Brown and R. Royston and S. Waldbusser",
TITLE="Modem Management Information Base {(MIB)} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1696,
PAGES=31,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
dial-up modems and similar dial-up devices. This MIB module provides a
set of objects that are the minimum necessary to provide the ability to
monitor and control those devices, and is consistent with the SNMP
framework and existing SNMP standards.",
URL="http://www.rfc-editor.org/rfc/rfc1696.txt"
}

@TECHREPORT{rfc1697,
EDITOR="D. Brower and B. Purvy and A. Daniel",
TITLE="Relational Database Management System {(RDBMS)} Management Information Base
{(MIB)} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1697,
PAGES=38,
DAYS=15,
MONTH=aug,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
relational database (RDBMS) implementations.",
URL="http://www.rfc-editor.org/rfc/rfc1697.txt"
}

@TECHREPORT{rfc1698,
AUTHOR="P. Furniss",
TITLE="Octet Sequences for {Upper-Layer} {OSI} to Support Basic Communications
Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1698,
PAGES=29,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT={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. 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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc1698.txt"
}

@TECHREPORT{rfc1700,
AUTHOR="J. F. Reynolds and J. B. Postel",
TITLE="Assigned Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1700,
PAGES=230,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT={This RFC is a snapshot of the ongoing process of the
assignment of protocol parameters for the Internet protocol suite. To
make the current information readily available the assignments are kept
up-to- date in a set of online text files. This RFC has been assembled
by catinating these files together with a minimum of formatting {"}glue{"}.
The authors appologize for the somewhat rougher formatting and style
than is typical of most RFCs.},
URL="http://www.rfc-editor.org/rfc/rfc1700.txt"
}

@TECHREPORT{rfc1701,
AUTHOR="S. Hanks and T. Li and D. Farinacci and P. Traina",
TITLE="Generic Routing Encapsulation {(GRE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1701,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT="This document specifies a protocol for performing
encapsulation of an arbitrary network layer protocol over another
arbitrary network layer protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1701.txt"
}

@TECHREPORT{rfc1702,
AUTHOR="S. Hanks and T. Li and D. Farinacci and P. Traina",
TITLE="Generic Routing Encapsulation over {IPv4} networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1702,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT="In an earlier memo (RFC 1701), we described GRE, a mechanism
for encapsulating arbitrary packets within an arbitrary transport
protocol. This is a companion memo which describes the use of GRE with
IP. This memo addresses the case of using IP as the delivery protocol or
the payload protocol and the special case of IP as both the delivery and
payload. This memo also describes using IP addresses and autonomous
system numbers as part of a GRE source route.",
URL="http://www.rfc-editor.org/rfc/rfc1702.txt"
}

@TECHREPORT{rfc1704,
AUTHOR="N. Haller and R. Atkinson",
TITLE="On Internet Authentication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1704,
PAGES=17,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT="The authentication requirements of computing systems and
network protocols vary greatly with their intended use, accessibility,
and their network connectivity. This document describes a spectrum of
authentication technologies and provides suggestions to protocol
developers on what kinds of authentication might be suitable for some
kinds of protocols and applications used in the Internet. It is hoped
that this document will provide useful information to interested members
of the Internet community. Passwords, which are vulnerable to passive
attack, are not strong enough to be appropriate in the current Internet.
Further, there is ample evidence that both passive and active attacks
are not uncommon in the current Internet. The authors of this paper
believe that many protocols used in the Internet should have stronger
authentication mechanisms so that they are at least protected from
passive attacks.",
URL="http://www.rfc-editor.org/rfc/rfc1704.txt"
}

@TECHREPORT{rfc1705,
AUTHOR="R. Carlson and D. Ficarella",
TITLE="Six Virtual Inches to the Left: The Problem with {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1705,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list. This RFC
suggests that a new version of TCP (TCPng), and UDP, be developed and
deployed. It proposes that a globally unique address (TA) be assigned to
Transport layer protocol (TCP/UDP). The purpose of this TA is to
uniquely identify an Internet node without specifying any routing
information. A new version of TCP, and UDP, will need to be developed
describing the new header fields and formats. This new version of TCP
would contain support for high bandwidth-delay networks. Support for
multiple network layer (Internet Protocol) protocols is also possible
with this new TCP. Assigning an address to TCP/UDP would allow for the
support of multiple network layer protocols (IPng's). The TA would
identify the location of an Internet node. The IPng layer would provide
routing information to the Internet. Separating the location and routing
functions will greatly increase the versatility of the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc1705.txt"
}

@TECHREPORT{rfc1707,
AUTHOR="M. McGovern and R. Ullmann",
TITLE="{CATNIP:} Common Architecture for the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1707,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list. This paper
describes a common architecture for the network layer protocol. The
Common Architecture for Next Generation Internet Protocol (CATNIP)
provides a compressed form of the existing network layer protocols. Each
compression is defined so that the resulting network protocol data units
are identical in format. The fixed part of the compressed format is 16
bytes in length, and may often be the only part transmitted on the
subnetwork.",
URL="http://www.rfc-editor.org/rfc/rfc1707.txt"
}

@TECHREPORT{rfc1708,
AUTHOR="D. Gowin",
TITLE="{NTP} {PICS} {PROFORMA} - For the Network Time Protocol Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1708,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT="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. For more
information please contact Dr. David Mills at Mills(at)udel.edu or review
RFC 1305 for more information.",
URL="http://www.rfc-editor.org/rfc/rfc1708.txt"
}

@TECHREPORT{rfc1709,
AUTHOR="J. Gargano and D. Wasley",
TITLE="{K-12} Internetworking Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1709,
PAGES=26,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT={Many organizations concerned with K-12 educational issues and
the planning for the use of technology recognize the value of data
communications throughout the educational system. State sponsored
documents such as the California Department of Education's {"}Strategic
Plan for Information Technology{"} recommend the planning of voice, video
and data networks to support learning and educational administration,
but they do not provide specific technical direction. The institutions
that built the Internet and connected early in its development are early
adopters of technology, with technical staff dedicated to the planning
for and implementation of leading edge technology. The K-12 community
traditionally has not had this level of staffing available for
telecommunications planning. This document is intended to bridge that
gap and provides a recommended technical direction, an introduction to
the role the Internet now plays in K-12 education and technical
guidelines for building a campus data communications infrastructure that
provides internetworking services and connections to the Internet. This
RFC is the product of the Internet School Networking Working Group of
the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1709.txt"
}

@TECHREPORT{rfc1710,
AUTHOR="R. Hinden",
TITLE="Simple Internet Protocol Plus White Paper",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1710,
PAGES=23,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT="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(at)sunroof.eng.sun.com mailing
list.",
URL="http://www.rfc-editor.org/rfc/rfc1710.txt"
}

@TECHREPORT{rfc1711,
AUTHOR="J. Houttuin",
TITLE="Classifications in E-mail Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1711,
PAGES=19,
DAYS=15,
MONTH=oct,
YEAR=1994,
ABSTRACT="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. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1711.txt"
}

@TECHREPORT{rfc1712,
AUTHOR="C. Farrell and M. Schulze and S. Pleitner and D. Baldoni",
TITLE="{DNS} Encoding of Geographical Location",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1712,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1712.txt"
}

@TECHREPORT{rfc1713,
AUTHOR="A. Romao",
TITLE="Tools for {DNS} debugging",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1713,
PAGES=13,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1713.txt"
}

@TECHREPORT{rfc1714,
AUTHOR="S. Williamson and M. Kosters",
TITLE="Referral Whois Protocol {(RWhois)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1714,
PAGES=46,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1714.txt"
}

@TECHREPORT{rfc1715,
AUTHOR="C. Huitema",
TITLE="The H Ratio for Address Assignment Efficiency",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1715,
PAGES=4,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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(at)sunroof.eng.sun.com mailing
list.",
URL="http://www.rfc-editor.org/rfc/rfc1715.txt"
}

@TECHREPORT{rfc1716,
AUTHOR="P. Almquist and F. Kastenholz",
TITLE="Towards Requirements for {IP} Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1716,
PAGES=186,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT={This document is a snapshot of the work of the Router
Requirements working group as of November 1991. At that time, the
working group had essentially finished its task. There were some final
technical matters to be nailed down, and a great deal of editing needed
to be done in order to get the document ready for publication.
Unfortunately, these tasks were never completed. t the request of the
Internet Area Director, the current editor took the last draft of the
document and, after consulting the mailing list archives, meeting
minutes, notes, and other members of the working group, edited the
document to its current form. This effort included the following tasks:
1) Deleting all the parenthetical material (such as editor's comments).
Useful information was turned into DISCUSSION sections, the rest was
deleted. 2) Completing the tasks listed in the last draft's To be Done
sections. As a part of this task, a new {"}to be done{"} list was developed
and included as an appendix to the current document. 3) Rolling Philip
Almquist's {"}Ruminations on the Next Hop{"} and {"}Ruminations on Route
Leaking{"} into this document. These represent significant work and should
be kept. 4) Fulfilling the last intents of the working group as
determined from the archival material. The intent of this effort was to
get the document into a form suitable for publication as an Historical
RFC so that the significant work which went into the creation of this
document would be preserved. The goal of this work is to replace
RFC-1009, Requirements for Internet Gateways with a new document. This
memo is an intermediate step toward that goal. It defines and discusses
requirements for devices which perform the network layer forwarding
function of the Internet protocol suite. The Internet community usually
refers to such devices as IP routers or simply routers; The OSI
community refers to such devices as intermediate systems. Many older
Internet documents refer to these devices as gateways, a name which more
recently has largely passed out of favor to avoid confusion with
application gateways.},
URL="http://www.rfc-editor.org/rfc/rfc1716.txt"
}

@TECHREPORT{rfc1717,
AUTHOR="K. Sklower and B. Lloyd and G. McGregor and D. Carr",
TITLE="The {PPP} Multilink Protocol {(MP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1717,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1717.txt"
}

@TECHREPORT{rfc1718,
AUTHOR="Ietf Secretariat and G. Malkin",
TITLE="The Tao of {IETF} - A Guide for New Attendees of the Internet Engineering
Task Force",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1718,
PAGES=23,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1718.txt"
}

@TECHREPORT{rfc1719,
AUTHOR="P. Gross",
TITLE="A Direction for {IPng}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1719,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list. This RFC specifies criteria
related to mobility for consideration in design and selection of the
Next Generation of IP.",
URL="http://www.rfc-editor.org/rfc/rfc1719.txt"
}

@TECHREPORT{rfc1721,
AUTHOR="G. Malkin",
TITLE="{RIP} Version 2 Protocol Analysis",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1721,
PAGES=4,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1721.txt"
}

@TECHREPORT{rfc1722,
AUTHOR="G. Malkin",
TITLE="{RIP} Version 2 Protocol Applicability Statement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1722,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1722.txt"
}

@TECHREPORT{rfc1723,
AUTHOR="G. Malkin",
TITLE="{RIP} Version 2 - Carrying Additional Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1723,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT={This document specifies an extension of the Routing
Information Protocol (RIP), as defined in RFC XXX, 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. The RIP-2 protocol
analysis is documented in RFC 1721. The RIP-2 applicability statement is
document in RFC 1722. The RIP-2 MIB description is defined in RFC 1724.
This memo obsoletes RFC 1389.},
URL="http://www.rfc-editor.org/rfc/rfc1723.txt"
}

@TECHREPORT{rfc1724,
AUTHOR="G. Malkin and F. Baker",
TITLE="{RIP} Version 2 {MIB} Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1724,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing RIP Version 2.",
URL="http://www.rfc-editor.org/rfc/rfc1724.txt"
}

@TECHREPORT{rfc1725,
AUTHOR="J. Myers and M. P. Rose",
TITLE="Post Office Protocol - Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1725,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=1994,
ABSTRACT={This memo is a revision to RFC 1460, a Draft Standard. It
makes the following changes from that document: removed text regarding
{"}split-UA model{"}, which didn't add anything to the understanding of
POP;
clarified syntax of commands, keywords, and arguments; clarified
behavior on broken connection; explicitly permitted an inactivity
autologout timer; clarified the requirements of the {"}exclusive-access
lock{"}; removed implementation-specific wording regarding the parsing of
the maildrop; allowed servers to close the connection after a failed
authentication command; removed the LAST command; fixed typo in example
of TOP command; clarified that the second argument to the TOP command is
non- negative; added the optional UIDL command; added warning regarding
length of shared secrets with APOP; added additional warnings to the
security considerations section.},
URL="http://www.rfc-editor.org/rfc/rfc1725.txt"
}

@TECHREPORT{rfc1726,
AUTHOR="C. Partridge and F. Kastenholz",
TITLE="Technical Criteria for Choosing {IP} The Next Generation {(IPng)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1726,
PAGES=31,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list. This RFC specifies criteria
related to mobility for consideration in design and selection of the
Next Generation of IP.",
URL="http://www.rfc-editor.org/rfc/rfc1726.txt"
}

@TECHREPORT{rfc1727,
AUTHOR="C. Weider and P. Deutsch",
TITLE="A Vision of an Integrated Internet Information Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1727,
PAGES=11,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1727.txt"
}

@TECHREPORT{rfc1728,
AUTHOR="C. Weider",
TITLE="Resource Transponders",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1728,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1728.txt"
}

@TECHREPORT{rfc1729,
AUTHOR="C. A. Lynch",
TITLE="Using the {Z39.50} Information Retrieval Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1729,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="This memo describes an approach to the implementation of the
ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP
environment which is currently in wide use by the Z39.50 implementor
community.",
URL="http://www.rfc-editor.org/rfc/rfc1729.txt"
}

@TECHREPORT{rfc1730,
AUTHOR="M. R. Crispin",
TITLE="Internet Message Access Protocol - Version 4",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1730,
PAGES=73,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT={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. 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). IMAP4 supports a single server. A
mechanism for supporting multiple IMAP4 servers is in progress. IMAP4
does not specify a means of posting mail; this function is handled by a
mail transfer protocol such as SMTP. IMAP4 is designed to be upwards
compatible from the IMAP2 protocol. Compatibility issues are discussed
in RFC 1732. This RFC is a product of the Internet Message Access
Protocol Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1730.txt"
}

@TECHREPORT{rfc1731,
AUTHOR="J. Myers",
TITLE="{IMAP4} Authentication Mechanisms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1731,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="The Internet Message Access Protocol, Version 4 contains the
AUTHENTICATE command, for identifying and authenticating a user to an
IMAP4 server and for optionally negotiating a protection mechanism for
subsequent protocol interactions. This document describes several
authentication mechanisms for use by the IMAP4 AUTHENTICATE command.
This RFC is a product of the Internet Message Access Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1731.txt"
}

@TECHREPORT{rfc1732,
AUTHOR="M. R. Crispin",
TITLE="{IMAP4} Compatibility with {IMAP2} and {IMAP2bis}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1732,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT={This RFC is a summary of hints and recommendations to enable
an IMAP4 implementation to interoperate with implementations that
conform to earlier specifications. None of these hints and
recommendations are required by the IMAP4 specification; implementors
must decide for themselves whether they want their implementation to
fail if it encounters old software. IMAP4 has been designed to be
upwards compatible with earlier specifications. For the most part, IMAP4
facilities that were not in earlier specifications should be invisible
to clients unless the client asks for the facility. In some cases, older
servers may support some of the capabilities listed as being {"}new in
IMAP4{"} as experimental extensions to the IMAP2 protocol described in RFC
1176. This information may not be complete; it reflects current
knowledge of server and client implementations as well as {"}folklore{"}
acquired in the evolution of the protocol. This RFC is a product of the
Internet Message Access Protocol Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1732.txt"
}

@TECHREPORT{rfc1733,
AUTHOR="M. R. Crispin",
TITLE="Distributed Electronic Mail Models in {IMAP4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1733,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="There are three fundamental models of client/server email:
offline, online, and disconnected use. IMAP4 can be used in any one of
these three models. This RFC is a product of the Internet Message Access
Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1733.txt"
}

@TECHREPORT{rfc1734,
AUTHOR="J. Myers",
TITLE="{POP3} {AUTHentication} command",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1734,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="This document describes the optional AUTH command, for
indicating an authentication mechanism to the server, performing an
authentication protocol exchange, and optionally negotiating a
protection mechanism for subsequent protocol interactions. The
authentication and protection mechanisms used by the POP3 AUTH command
are those used by IMAP4.",
URL="http://www.rfc-editor.org/rfc/rfc1734.txt"
}

@TECHREPORT{rfc1735,
AUTHOR="J. Heinanen and R. Govindan",
TITLE="{NBMA} Address Resolution Protocol {(NARP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1735,
PAGES=11,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1735.txt"
}

@TECHREPORT{rfc1737,
AUTHOR="K. Sollins and L. Masinter",
TITLE="Functional Requirements for Uniform Resource Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1737,
PAGES=7,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="This document specifies a minimum set of requirements for a
kind of Internet resource identifier known as Uniform Resource Names
(URNs). URNs fit within a larger Internet information architecture,
which in turn is composed of, additionally, Uniform Resource
Characteristics (URCs), and Uniform Resource Locators (URLs). URNs are
used for identification, URCs for including meta-information, and URLs
for locating or finding resources. It is provided as a basis for
evaluating standards for URNs. The discussions of this work have
occurred on the mailing list uri(at)bunyip.com and at the URI Working Group
sessions of the IETF. The requirements described here are not
necessarily exhaustive; for example, there are several issues dealing
with support for replication of resources and with security that have
been discussed; however, the problems are not well enough understood at
this time to include specific requirements in those areas here.",
URL="http://www.rfc-editor.org/rfc/rfc1737.txt"
}

@TECHREPORT{rfc1739,
AUTHOR="G. Kessler and S. Shepard",
TITLE="A Primer On Internet and {TCP/IP} Tools",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1739,
PAGES=46,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="This memo is an introductory guide to some of the TCP/IP and
Internet tools and utilities that allow users to access the wide variety
of information on the network, from determining if a particular host is
up to viewing a multimedia thesis on foreign policy. It also describes
discussion lists accessible from the Internet, ways to obtain Internet
documents, and resources that help users weave their way through the
Internet. This memo may be used as a tutorial for individual
self-learning, a step-by-step laboratory manual for a course, or as the
basis for a site's users manual. It is intended as a basic guide only
and will refer to other sources for more detailed information.",
URL="http://www.rfc-editor.org/rfc/rfc1739.txt"
}

@TECHREPORT{rfc1740,
AUTHOR="P. Faltstrom and D. H. Crocker and E. Fair",
TITLE="{MIME} Encapsulation of Macintosh Files - {MacMIME}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1740,
PAGES=16,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="This memo describes the format to use when sending Apple
Macintosh files via MIME (Multipurpose Internet Mail Extensions). The
format is compatible with existing mechanisms for distributing Macintosh
files, while allowing non-Macintosh systems access to data in
standardized formats.",
URL="http://www.rfc-editor.org/rfc/rfc1740.txt"
}

@TECHREPORT{rfc1741,
AUTHOR="P. Faltstrom and D. H. Crocker and E. Fair",
TITLE="{MIME} Content Type for {BinHex} Encoded Files",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1741,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="This memo describes the format to use when sending BinHex4.0
files via MIME (Multipurpose Internet Mail Extensions). 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/applefile (RFC
1740) for maximum interoperability.",
URL="http://www.rfc-editor.org/rfc/rfc1741.txt"
}

@TECHREPORT{rfc1743,
AUTHOR="K. McCloghrie and E. Decker",
TITLE="{IEEE} {802.5} {MIB} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1743,
PAGES=25,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
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. This memo is a replacement for RFC 1231. This RFC
is a product of the Interfaces MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1743.txt"
}

@TECHREPORT{rfc1744,
AUTHOR="G. Huston",
TITLE="Observations on the Management of the Internet Address Space",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1744,
PAGES=12,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1744.txt"
}

@TECHREPORT{rfc1745,
AUTHOR="K. Varadhan and S. Hares and Y. Rekhter",
TITLE="{BGP4/IDRP} for {IP---OSPF} Interaction",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1745,
PAGES=19,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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. This RFC is the product of the Inter-Domain Routing Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1745.txt"
}

@TECHREPORT{rfc1746,
AUTHOR="B. Manning and D. Perkins",
TITLE="Ways to Define User Expectations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1746,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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. This RFC is the product of the
Internet School Networking Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1746.txt"
}

@TECHREPORT{rfc1749,
AUTHOR="K. McCloghrie and F. Baker and E. Decker",
TITLE="{IEEE} {802.5} Station Source Routing {MIB} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1749,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used by IEEE
802.5 end-stations for managing source routes on a Token Ring network
where IEEE source-routing is in use. IEEE source-routing is described in
802.5 Token Ring Access Method and Physical Layer Specifications and
related ISO publications. This memo is an incremental update to RFC
1748. It is documented separately from the RFC 1748 solely due to the
latter's maturity within the Internet standardization process. This RFC
is the product of the Interfaces MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1749.txt"
}

@TECHREPORT{rfc1750,
AUTHOR="D. Eastlake 3rd and S. D. Crocker and J. Schiller",
TITLE="Randomness Recommendations for Security",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1750,
PAGES=30,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1750.txt"
}

@TECHREPORT{rfc1751,
AUTHOR="D. McDonald",
TITLE="A Convention for {Human-Readable} 128-bit Keys",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1751,
PAGES=15,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="The Internet community has begun to address matters of
security. Recent standards, including version 2 of SNMP, have explicit
requirements for an authentication mechanism. These require use of a
keyed message-digest algorithm, MD5, with a key size of 128-bits. A
128-bit key, while sufficiently strong, is hard for most people to read,
remember, and type in. This memo proposes a convention for use with
Internet applications and protocols using 128-bit cryptographic keys.",
URL="http://www.rfc-editor.org/rfc/rfc1751.txt"
}

@TECHREPORT{rfc1753,
AUTHOR="N. Chiappa",
TITLE="{IPng} Technical Requirements Of the Nimrod Routing and Addressing
Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1753,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=1994,
ABSTRACT="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(at)munnari.oz.au mailing list. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1753.txt"
}

@TECHREPORT{rfc1736,
AUTHOR="J. Kunze",
TITLE="Functional Recommendations for Internet Resource Locators",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1736,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1995,
ABSTRACT="This document specifies a minimum set of requirements for
Internet resource locators (IRLs), which convey location and access
information for resources. Typical examples of resources include network
accessible documents, WAIS databases, FTP servers, and Telnet
destinations. This RFC is a product of the Uniform Resource Identifiers
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1736.txt"
}

@TECHREPORT{rfc1742,
AUTHOR="S. Waldbusser and K. Frisa",
TITLE="{AppleTalk} Management Information Base {II}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1742,
PAGES=84,
DAYS=15,
MONTH=jan,
YEAR=1995,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing AppleTalk
networks. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1742.txt"
}

@TECHREPORT{rfc1747,
EDITOR="J. Hilgeman and Tpc Chairs and S. Nix",
TITLE="Definitions of Managed Objects for {SNA} Data Link Control {(SDLC)} using
{SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1747,
PAGES=67,
DAYS=15,
MONTH=jan,
YEAR=1995,
ABSTRACT="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
RFC identifies managed objects for SNA Synchronous Data Link Control
(SDLC) links only. This RFC is a product of the SNA DLC Services MIB
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1747.txt"
}

@TECHREPORT{rfc1752,
AUTHOR="S. Bradner and Allison Mankin",
TITLE="The Recommendation for the {IP} Next Generation Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1752,
PAGES=52,
DAYS=15,
MONTH=jan,
YEAR=1995,
ABSTRACT="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). This RFC is the product of the IPng
Area of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1752.txt"
}

@TECHREPORT{rfc1754,
AUTHOR="M. Laubach",
TITLE="{IP} over {ATM} Working Group's Recommendations for the {ATM} Forum's
Multiprotocol {BOF} Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1754,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1995,
ABSTRACT="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. This RFC is a product of the
IP over ATM Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1754.txt"
}

@TECHREPORT{rfc1755,
AUTHOR="M. {P{\'{e}}rez} and F. Liaw and Allison Mankin and E. Hoffman and D.
Grossman and A. Malis",
TITLE="{ATM} Signaling Support for {IP} over {ATM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1755,
PAGES=32,
DAYS=15,
MONTH=feb,
YEAR=1995,
ABSTRACT="This memo describes the ATM call control signaling exchanges
needed to support Classical IP over ATM implementations as described in
RFC 1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services
as specified in the ATM Forum User-Network Interface (UNI) Specification
Version 3.1 [ATMF94]. 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.
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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1755.txt"
}

@TECHREPORT{rfc1756,
AUTHOR="T. Rinne",
TITLE="Remote Write Protocol - Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1756,
PAGES=11,
DAYS=15,
MONTH=jan,
YEAR=1995,
ABSTRACT="It is often convenient to use electronic communication
somewhat lighter than electronic mail. Sometimes even the use of the
talk(1) *) program seems like overkill. We like to offer to user
something like UNIX **) command write(1) ***) except that it can also
pass messages through the network instead of the single host. There have
been few programs offering this kind of service, but they have either
based on SUN-RPC protocol or used a strictly undocumented protocol. This
document describes a simple Remote Write Protocol (RWP) that should have
been documented at least 10 years ago. But late is better than never.
Version number of the RWP protocol in this document is 1.0.",
URL="http://www.rfc-editor.org/rfc/rfc1756.txt"
}

@TECHREPORT{rfc1757,
AUTHOR="S. Waldbusser",
TITLE="Remote Network Monitoring Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1757,
PAGES=91,
DAYS=15,
MONTH=feb,
YEAR=1995,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring devices. This RFC is the product of the Remote Network
Monitoring Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1757.txt"
}

@TECHREPORT{rfc1758,
AUTHOR=" {{North American Directory Forum}}",
TITLE="{NADF} Standing Documents: A Brief Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1758,
MONTH=feb,
YEAR=1995,
ABSTRACT="The North American Directory Forum (NADF) is a collection of
service providers which plans to cooperatively offer a Public Directory
Service in North America using the CCITT X.500 Recommendations. Although
many groups are working on realizing X.500, the NADF is unique in that
it must achieve a cooperative service offered by competing providers.
The purpose of this document is to provide a brief overview of the
NADF's Standing Document series.",
URL="http://www.rfc-editor.org/rfc/rfc1758.txt"
}

@TECHREPORT{rfc1759,
AUTHOR="R. E. Smith and F. Wright and T. Hastings and S. Zilles and J. Gyllenskog",
TITLE="Printer {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1759,
PAGES=113,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="The management of producing a printed document, in any
computer environment, is a complex subject. Basically, the task can be
divided into two overlapping pieces, the management of printing and the
management of the printer. Printing encompasses the entire process of
producing a printed document from generation of the file to be printed,
selection of a printer, choosing printing properties, routing, queuing,
resource management, scheduling, and final printing including notifying
the user. Most of the printing process is outside the scope of the model
presented here; only the management of the printer is covered. This RFC
is the product of the Printer MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1759.txt"
}

@TECHREPORT{rfc1760,
AUTHOR="N. Haller",
TITLE="The {S/KEY} {One-Time} Password System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1760,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=1995,
ABSTRACT="This document describes the S/KEY* One-Time Password system as
released for public use by Bellcore.",
URL="http://www.rfc-editor.org/rfc/rfc1760.txt"
}

@TECHREPORT{rfc1761,
AUTHOR="B. Callaghan and R. Gilligan",
TITLE="Snoop Version 2 Packet Capture File Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1761,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1995,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1761.txt"
}

@TECHREPORT{rfc1762,
AUTHOR="S. Senum",
TITLE="The {PPP} {DECnet} Phase {IV} Control Protocol {(DNCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1762,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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. 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). This RFC is the product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1762.txt"
}

@TECHREPORT{rfc1763,
AUTHOR="S. Senum",
TITLE="The {PPP} Banyan Vines Control Protocol {(BVCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1763,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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. This document defines the Network Control
Protocol for establishing and configuring the Banyan VINES protocol over
PPP. This RFC is the product of the Point-to-Point Protocol Extensions
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1763.txt"
}

@TECHREPORT{rfc1764,
AUTHOR="S. Senum",
TITLE="The {PPP} {XNS} {IDP} Control Protocol {(XNSCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1764,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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. This document defines the Network Control
Protocol for establishing and configuring the Xerox Network Systems
(XNS) Internet Datagram Protocol (IDP) over PPP. This RFC is the product
of the Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1764.txt"
}

@TECHREPORT{rfc1765,
AUTHOR="J. Moy",
TITLE="{OSPF} Database Overflow",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1765,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT={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. This memo is a
product of the Open Shortest Path First Working Group of the IETF},
URL="http://www.rfc-editor.org/rfc/rfc1765.txt"
}

@TECHREPORT{rfc1766,
AUTHOR="H. Alvestrand",
TITLE="Tags for the Identification of Languages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1766,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="This document describes a language tag for use in cases where
it is desired to indicate the language used in an information object. 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. This RFC is a product of the Mail Extensions
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1766.txt"
}

@TECHREPORT{rfc1767,
AUTHOR="D. H. Crocker",
TITLE="{MIME} Encapsulation of {EDI} Objects",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1767,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="Electronic Data Interchange (EDI) provides a means of
conducting structured transactions between trading partners. The
delivery mechanism for these types of transactions in a paper world has
been the postal system, so it is to be expected that electronic mail
would serve as a natural delivery mechanism for electronic transactions.
This specification permits formatted electronic business interchanges to
be encapsulated within MIME messages. For the specification effort, the
basic building block from EDI is an interchange. This specification
pertains only to the encapsulation of EDI objects within the MIME
environment. It intends no changes in those objects from the primary
specifications that define the syntax and semantics of them. EDI
transactions take place through a variety of carriage and exchange
mechanisms. This specification adds to that repertoire, by permitting
convenient carriage through Internet email. This RFC is the product of
the Electronic Data Interchange Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1767.txt"
}

@TECHREPORT{rfc1768,
AUTHOR="D. Marlow",
TITLE="Host Group Extensions for {CLNP} Multicasting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1768,
PAGES=45,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1768.txt"
}

@TECHREPORT{rfc1769,
AUTHOR="D. L. Mills",
TITLE="Simple Network Time Protocol {(SNTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1769,
PAGES=14,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1769.txt"
}

@TECHREPORT{rfc1770,
AUTHOR="C. J. Graff",
TITLE="{IPv4} Option for Sender Directed {Multi-Destination} Delivery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1770,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1770.txt"
}

@TECHREPORT{rfc1771,
AUTHOR="Y. Rekhter and T. Li",
TITLE="A Border Gateway Protocol 4 {(BGP-4)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1771,
PAGES=57,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT={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. This RFC is a
product of the Inter-Domain Routing Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1771.txt"
}

@TECHREPORT{rfc1772,
AUTHOR="Y. Rekhter and P. Gross",
TITLE="Application of the Border Gateway Protocol in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1772,
PAGES=19,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT={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. This RFC is a product of the Inter-Domain
Routing Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1772.txt"
}

@TECHREPORT{rfc1773,
AUTHOR="P. Traina",
TITLE="Experience with the {BGP-4} protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1773,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="The purpose of this memo is to document how the requirements
for advancing a routing protocol to Draft Standard have been satisfied
by Border Gateway Protocol version 4 (BGP-4). This report documents
experience with BGP. This RFC is a product of the Inter-Domain Routing
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1773.txt"
}

@TECHREPORT{rfc1774,
EDITOR="P. Traina",
TITLE="{BGP-4} Protocol Analysis",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1774,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="The purpose of this report is to document how the requirements
for advancing a routing protocol to Draft Standard have been satisfied
by the Border Gateway Protocol version 4 (BGP-4). This report summarizes
the key features of BGP, and analyzes the protocol with respect to
scaling and performance. This RFC is a product of the Inter-Domain
Routing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1774.txt"
}

@TECHREPORT{rfc1775,
AUTHOR="D. H. Crocker",
TITLE={To Be {"}On{"} the Internet},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1775,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1775.txt"
}

@TECHREPORT{rfc1776,
AUTHOR="S. D. Crocker",
TITLE="The Address is the Message",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1776,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT="Declaring that the address is the message, the IPng WG has
selected a packet format which includes 1696 bytes of address space.
This length is a multiple of 53 and is completely compatible with ATM
architecture. Observing that it's not what you know but who you know,
the IPng focused on choosing an addressing scheme that makes it possible
to talk to everyone while dispensing with the irrelevant overhead of
actually having to say anything.",
URL="http://www.rfc-editor.org/rfc/rfc1776.txt"
}

@TECHREPORT{rfc1777,
AUTHOR="W. Yeong and T. Howes and S. E. Kille",
TITLE="Lightweight Directory Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1777,
PAGES=22,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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.
This RFC is the product of the Internet Directories Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1777.txt"
}

@TECHREPORT{rfc1778,
AUTHOR="T. Howes and S. E. Kille and W. Yeong and C. Robbins",
TITLE="The String Representation of Standard Attribute Syntaxes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1778,
PAGES=12,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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. This RFC is the
product of the Access/Synchronization of the Internet Directories
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1778.txt"
}

@TECHREPORT{rfc1779,
AUTHOR="S. E. Kille",
TITLE="A String Representation of Distinguished Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1779,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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. This RFC is the product
of the Access/Synchronization of the Internet Directories Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1779.txt"
}

@TECHREPORT{rfc1780,
AUTHOR="Editor J. Postel",
EDITOR="J. B. Postel",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1780,
PAGES=39,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="This memo describes the state of standardization of protocols
used in the Internet as determined by the Internet Architecture Board
(IAB). This memo is an Internet Standard. Distribution of this memo is
unlimited.",
URL="http://www.rfc-editor.org/rfc/rfc1780.txt"
}

@TECHREPORT{rfc1781,
AUTHOR="S. E. Kille",
TITLE="Using the {OSI} Directory to Achieve User Friendly Naming",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1781,
PAGES=26,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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: a user oriented notation; guessability. 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 RFC 1779, and it is
intended that these specifications are compatible. This RFC is the
product of the Access/Synchronization of the Internet Directories
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1781.txt"
}

@TECHREPORT{rfc1782,
AUTHOR="G. Malkin and A. Harkin",
TITLE="{TFTP} Option Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1782,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="The Trivial File Transfer Protocol (STD 33, RFC 1350) 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. This RFC is the product of the TFTP Extensions Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1782.txt"
}

@TECHREPORT{rfc1783,
AUTHOR="G. Malkin and A. Harkin",
TITLE="{TFTP} Blocksize Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1783,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="The Trivial File Transfer Protocol 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-byte blocksize is not the most efficient for use on a LAN whose MTU
may 1500 bytes or greater. 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
RFC 1782.",
URL="http://www.rfc-editor.org/rfc/rfc1783.txt"
}

@TECHREPORT{rfc1784,
AUTHOR="G. Malkin and A. Harkin",
TITLE="{TFTP} Timeout Interval and Transfer Size Options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1784,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="The Trivial File Transfer Protocol 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 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 RFC 1782.",
URL="http://www.rfc-editor.org/rfc/rfc1784.txt"
}

@TECHREPORT{rfc1785,
AUTHOR="G. Malkin and A. Harkin",
TITLE="{TFTP} Option Negotiation Analysis",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1785,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="The TFTP option negotiation mechanism, proposed in RFC 1782,
is a backward-compatible extension to the TFTP protocol, defined in RFC
1350. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1785.txt"
}

@TECHREPORT{rfc1786,
AUTHOR="T. Bates and E. Gerich and L. Joncheray and J-m. Jouanigot and D.
Karrenberg and M. Terpstra and J. Yu",
TITLE="Representation of {IP} Routing Policies in a Routing Registry (ripe-81++)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1786,
PAGES=83,
DAYS=15,
MONTH=mar,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1786.txt"
}

@TECHREPORT{rfc1787,
AUTHOR="Y. Rekhter",
TITLE="Routing in a Multi-provider Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1787,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT="This document was prepared by the author on behalf of the
Internet Architecture Board (IAB). It is offered by the IAB to stimulate
discussion. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1787.txt"
}

@TECHREPORT{rfc1788,
AUTHOR="W. Simpson",
TITLE="{ICMP} Domain Name Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1788,
PAGES=7,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT="This document specifies ICMP messages for learning the Fully
Qualified Domain Name associated with an IP address. IESG Note: An
Internet Engineering Steering Group comment from the co-Area Director
for IPng: Please note well that this memo is an individual product of
the author. It presents one view of the IN-ADDR mechanism, motivated by
discussion in the IPNG WG of the difficulty of secure, dynamic update of
the reverse tree. Other IETF discussion and ongoing standards work on
this area will be found in the IP Next Generation (ipngwg), DNS IXFR,
Notification, and Dynamic Update (dnsind), DNS Security (dnssec) working
groups.",
URL="http://www.rfc-editor.org/rfc/rfc1788.txt"
}

@TECHREPORT{rfc1789,
AUTHOR="C. Yang",
TITLE="{INETPhone:} Telephone Services and Servers on Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1789,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT={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. IESG Note: Internet Engineering
Steering Group comment from the Transport Area Director: Please note
well that this memo is an individual product of the author. Work on
standards and technology related to this topic is additionally taking
place in the IETF in the Multiparty MUltimedia SessIon Control Working
Group (MMUSIC).},
URL="http://www.rfc-editor.org/rfc/rfc1789.txt"
}

@TECHREPORT{rfc1790,
AUTHOR="V. G. Cerf",
TITLE="An Agreement between the Internet Society and Sun Microsystems, Inc in the
Matter of {ONC} {RPC} and {XDR} Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1790,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT={This Request for Comments records an agreement between SUN
Microsystems, Inc. and the Internet Society to permit the flow of SUN's
Open Network Computing Remote Procedure Call and External Data
Representation specifications into the Internet Standards process
conducted by the Internet Engineering Task Force. It should be noted by
readers that paragraph 4 means, in part, that someone or some
organization other than the named {"}Licensees{"} must be separately
{"}licensed{"} to make use of these specifications for implementation or
other purposes. SUN Microsystems commits to providing such a license
under {"}substantially similar terms{"} and at no charge. If the referenced
RFCs are re-issued as Proposed Standards, SUN could offer a blanket
license to implementors which could, itself, be documented and recorded
as an RFC for reference. Note: This RFC is NOT a standard. It is an
official public record of an agreement between SUN Microsystems and the
Internet Society. The referenced RFC 1057 dated June 1988 ({"}RFC: Remote
Procedure Call Protocol Specification Version 2) and RFC 1014 dated June
1987 ({"}XDR: External Data Representation Standard) are not attached to
the document below, but are incorporated by reference.},
URL="http://www.rfc-editor.org/rfc/rfc1790.txt"
}

@TECHREPORT{rfc1791,
AUTHOR="T. Sung",
TITLE="{TCP} And {UDP} Over {IPX} Networks With Fixed Path {MTU}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1791,
PAGES=12,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT="Most of network applications run on some sort of transports.
And, if one is to let such applications to run over a foreign network
protocol, the simplest way would be to allow the applications'
transports to run over that network protocol. For TCP/IP applications,
that transport is TCP or UDP. Hence, to let TCP/IP applications run over
IPX, we would need to have TCP and UDP run over IPX. And, once TCP and
UDP are allowed to run over IPX, all TCP and UDP based applications,
such as HTTP for WWW, or NFS, can easily be made to work over IPX
networks. IESG Note: Internet Engineering Steering Group comment from
the Area Director for Transport Services: Please note well that this
memo is an individual product of the author. Implementation experience,
particularly on the effectiveness of the protocols in dual-stack
environments, is needed.",
URL="http://www.rfc-editor.org/rfc/rfc1791.txt"
}

@TECHREPORT{rfc1792,
AUTHOR="T. Sung",
TITLE="{TCP/IPX} Connection Mib Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1792,
PAGES=9,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT="Traditionally, TCP and UDP runs over IP. STD 17, RFC 1213
defines TCP connection MIB object and UDP listener object assuming just
that. For TCP and UDP running over IPX, tcpConnTable and udpTable
objects from RFC 1213 cannot be used since they define the address to be
of type IpAddress. As such, we need to define new objects that can
properly describe TCP and UDP connections over IPX. New MIB objects,
tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are
presented in this paper, to be used in place of tcpConnTable and
udpListenerTable when TCP and UDP are running over IPX. IESG Note:
Internet Engineering Steering Group comment from the Area Director for
Transport Services: Please note well that this memo is an individual
product of the author. Implementation experience, particularly on the
effectiveness of the protocols in dual-stack environments, is needed.",
URL="http://www.rfc-editor.org/rfc/rfc1792.txt"
}

@TECHREPORT{rfc1793,
AUTHOR="J. Moy",
TITLE="Extending {OSPF} to Support Demand Circuits",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1793,
PAGES=32,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT={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. This RFC
is a product of the Open Shortest Path First IGP Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1793.txt"
}

@TECHREPORT{rfc1794,
AUTHOR="T. Brisco",
TITLE="{DNS} Support for Load Balancing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1794,
PAGES=7,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT="This RFC is meant to first chronicle a foray into the IETF DNS
Working Group, discuss other possible alternatives to provide/simulate
load balancing support for DNS, and to provide an ultimate, flexible
solution for providing DNS support for balancing loads of many types.",
URL="http://www.rfc-editor.org/rfc/rfc1794.txt"
}

@TECHREPORT{rfc1795,
AUTHOR="L. Wells and Tpc Chairs and A. Bartky and Witold Pedrycz",
TITLE="Data Link Switching: {Switch-to-Switch} Protocol {AIW} {DLSw} {RIG:} {DLSw}
Closed Pages, {DLSw} Standard Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1795,
PAGES=91,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1795.txt"
}

@TECHREPORT{rfc1796,
AUTHOR="C. Huitema and J. B. Postel and S. D. Crocker",
TITLE="Not All {RFCs} are Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1796,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=1995,
ABSTRACT="This document discusses the relationship of the Request for
Comments (RFCs) notes to Internet Standards.",
URL="http://www.rfc-editor.org/rfc/rfc1796.txt"
}

@TECHREPORT{rfc1797,
AUTHOR=" {{Internet Assigned Numbers Authority (IANA)}}",
TITLE="Class A Subnet Experiment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1797,
MONTH=apr,
YEAR=1995,
ABSTRACT="There appears to be some interest in experimenting with
subnetting the class A addresses. There is some evidence that not all
the routing software in use will deal correctly with subnetted class A
addresses. It also appears that actual use of subnetted class A
addresses may be necessary in the not too distant future. It is
suggested that conducting an experiment now to identify and fix any
software that does not properly handle subnetted class A addresses would
be useful and important.",
URL="http://www.rfc-editor.org/rfc/rfc1797.txt"
}

@TECHREPORT{rfc1798,
AUTHOR="A. Young",
TITLE="Connection-less Lightweight {X.500} Directory Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1798,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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). In particular, it is aimed at
avoiding the elapsed time that is associated with connection-oriented
communication and it facilitates use of the Directory in a manner
analagous to the DNS (Domain Name Service). It is specifically targeted
at simple lookup applications that require to read a small number of
attribute values from a single entry. It is intended to be a complement
to DAP and LDAP (Lightweight Directory Access Protocol). The protocol
specification draws heavily on that of LDAP. This memo was initiated in
the (now defunct) OSI Directory Services Working Group and completed by
the Access and Synchronization of the Internet Directories Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1798.txt"
}

@TECHREPORT{rfc1801,
AUTHOR="S. E. Kille",
TITLE="{MHS} use of the {X.500} Directory to support {MHS} Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1801,
PAGES=73,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT={MHS Routing is the problem of controlling the path of a
message as it traverses one or more MTAs to reach its destination
recipients. Routing starts with a recipient O/R Address, and parameters
associated with the message to be routed. The key problem in routing is
to map from an O/R Address onto an MTA (next hop). This shall be an MTA
which in some sense is {"}nearer{"} to the destination UA. This is done
repeatedly until the message can be directly delivered to the recipient
UA. There are a number of things which need to be considered to
determine this. This memo describes MHS Routing using X.500 Directory.
This RFC is a product of the MHS-DS Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1801.txt"
}

@TECHREPORT{rfc1802,
AUTHOR="H. Alvestrand and K. Jordan and S. Langlois and J. Romaguera",
TITLE="Introducing Project Long Bud: Internet Pilot Project for the Deployment of
{X.500} Directory Information in Support of {X.400} Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1802,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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. This RFC is the product of the MHS-DS Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1802.txt"
}

@TECHREPORT{rfc1803,
AUTHOR="R. Wright and A. Getchell and T. Howes and S. Sataluri and P. Yee and W.
Yeong",
TITLE="Recommendations for an {X.500} Production Directory Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1803,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT={This document contains a set of basic recommendations for a
country-level X.500 DSA (Directory System Agent). 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.
This RFC is the product of the Access, Searching and Indexing of
Directories Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1803.txt"
}

@TECHREPORT{rfc1804,
AUTHOR="G. Mansfield and P. Rajeev and S. V. Raghavan and T. Howes",
TITLE="Schema Publishing in {X.500} Directory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1804,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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. This RFC is a product of the Access, Searching
and Indexing of Directories Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1804.txt"
}

@TECHREPORT{rfc1805,
AUTHOR="A. Rubin",
TITLE="{Location-Independent} {Data/Software} Integrity Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1805,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1805.txt"
}

@TECHREPORT{rfc1806,
AUTHOR="R. Troost and S. Dorner",
TITLE="Communicating Presentation Information in Internet Messages: The
{Content-Disposition} Header",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1806,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT={This memo provides a mechanism whereby messages conforming to
the {"}MIME{"} (RFC 1521) specification can convey presentational
information. It specifies a new {"}Content-Disposition{"} header, optional
and valid for any RFC 1521 entity ({"}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.},
URL="http://www.rfc-editor.org/rfc/rfc1806.txt"
}

@TECHREPORT{rfc1807,
AUTHOR="R. Lasher and D. Cohen",
TITLE="A Format for Bibliographic Records",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1807,
PAGES=15,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1807.txt"
}

@TECHREPORT{rfc1808,
AUTHOR="R. Fielding",
TITLE="Relative Uniform Resource Locators",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1808,
PAGES=16,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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.
This RFC is the product of the Uniform Resource Identifiers Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1808.txt"
}

@TECHREPORT{rfc1809,
AUTHOR="C. Partridge",
TITLE="Using the Flow Label Field in {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1809,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1809.txt"
}

@TECHREPORT{rfc1810,
AUTHOR="J. Touch",
TITLE="Report on {MD5} Performance",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1810,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1810.txt"
}

@TECHREPORT{rfc1811,
AUTHOR=" {{Federal Networking Council}}",
TITLE="{U.S.} Government Internet Domain Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1811,
MONTH=jun,
YEAR=1995,
ABSTRACT={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. As a side effect, this reduces the
number of .GOV level registrations and reduces the workload on the
Internic.},
URL="http://www.rfc-editor.org/rfc/rfc1811.txt"
}

@TECHREPORT{rfc1812,
EDITOR="F. Baker",
TITLE="Requirements for {IP} Version 4 Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1812,
PAGES=175,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="This document is an updated version of RFC 1716, the
historical Router Requirements document. That RFC preserved the
significant work that went into the working group, but failed to
adequately describe current technology for the IESG to consider it a
current standard. The current editor had been asked to bring the
document up to date, so that it is useful as a procurement specification
and a guide to implementors. In this, he stands squarely on the
shoulders of those who have gone before him, and depends largely on
expert contributors for text. Any credit is theirs; the errors are his.
The content and form of this document are due, in large part, to the
working group's chair, and document's original editor and author: Philip
Almquist. It is also largely due to the efforts of its previous editor,
Frank Kastenholz. Without their efforts, this document would not exist.
This RFC is a product of the Router Requirements Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1812.txt"
}

@TECHREPORT{rfc1813,
AUTHOR="B. Callaghan and B. Pawlowski and P. Staubach",
TITLE="{NFS} Version 3 Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1813,
PAGES=126,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="This paper describes the NFS version 3 protocol. This paper is
provided so that people can write compatible implementations.",
URL="http://www.rfc-editor.org/rfc/rfc1813.txt"
}

@TECHREPORT{rfc1814,
AUTHOR="E. Gerich",
TITLE="Unique Addresses are Good",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1814,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1814.txt"
}

@TECHREPORT{rfc1815,
AUTHOR="M. Ohta",
TITLE="Character Sets {ISO-10646} and {ISO-10646-J-1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1815,
PAGES=6,
DAYS=15,
MONTH=jul,
YEAR=1995,
ABSTRACT="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. 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. This memo provides information on such
profiling, along with charset names to each profiled instance. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1815.txt"
}

@TECHREPORT{rfc1816,
AUTHOR="Federal Networking Council",
TITLE="{U.S.} Government Internet Domain Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1816,
MONTH=aug,
YEAR=1995,
URL="http://www.rfc-editor.org/rfc/rfc1816.txt"
}

@TECHREPORT{rfc1817,
AUTHOR="Y. Rekhter",
TITLE="{CIDR} and Classful Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1817,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1817.txt"
}

@TECHREPORT{rfc1818,
AUTHOR="J. B. Postel and T. Li and Y. Rekhter",
TITLE="Best Current Practices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1818,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc1818.txt"
}

@TECHREPORT{rfc1819,
EDITOR="L. Delgrossi and L. Berger",
TITLE="Internet Stream Protocol Version 2 {(ST2)} Protocol Specification - Version
{ST2+}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1819,
PAGES=109,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="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+. This specification
is a product of the STream Protocol Working Group of the Internet
Engineering Task Force.",
URL="http://www.rfc-editor.org/rfc/rfc1819.txt"
}

@TECHREPORT{rfc1820,
AUTHOR="E. Huizer",
TITLE="Multimedia E-mail {(MIME)} User Agent Checklist",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1820,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="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. This RFC is a product of the Mail
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1820.txt"
}

@TECHREPORT{rfc1821,
AUTHOR="M. Borden and E. Crawley and B. S. Davie and S. Batsell",
TITLE="Integration of Real-time Services in an {IP-ATM} Network Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1821,
PAGES=24,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1821.txt"
}

@TECHREPORT{rfc1822,
AUTHOR="J. Lowe",
TITLE="A Grant of Rights to Use a Specific {IBM} patent with Photuris",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1822,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This RFC records a grant by IBM Corporation to permit the
conditional free use of one of its patents. This grant is made to help
facilitate adoption of the Internet Key Management Protocol contribution
IBM has offered to the IETF. It should be noted that the confirmatory
license mentioned is optional. The grant is made in this RFC and parties
have it even if they do not request a confirmation from IBM. This memo
is NOT a standard. It is an official public record of a grant by IBM
Corporation for the use of a specific IBM patent in conjunction with the
Photuris key management protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1822.txt"
}

@TECHREPORT{rfc1823,
AUTHOR="T. Howes and M. Smith",
TITLE="The {LDAP} Application Program Interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1823,
PAGES=22,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document defines a C language application program
interface to the lightweight directory access protocol (LDAP). The LDAP
API is designed to be powerful, yet simple to use. It defines compatible
synchronous and asynchronous interfaces to LDAP to suit a wide variety
of applications. This document gives a brief overview of the LDAP model,
then an overview of how the API is used by an application program to
obtain LDAP information. The API calls are described in detail, followed
by an appendix that provides some example code demonstrating the use of
the API.",
URL="http://www.rfc-editor.org/rfc/rfc1823.txt"
}

@TECHREPORT{rfc1824,
AUTHOR="H. Danisch",
TITLE="The Exponential Security System {TESS:} An {Identity-Based} Cryptographic
Protocol for Authenticated {Key-Exchange} {(E.I.S.S.-Report} {1995/4)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1824,
PAGES=21,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1824.txt"
}

@TECHREPORT{rfc1825,
AUTHOR="R. Atkinson",
TITLE="Security Architecture for the Internet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1825,
PAGES=22,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This memo describes the security mechanisms for IP version 4
(IPv4) and IP version 6 (IPv6) and the services that they provide. Each
security mechanism is specified in a separate document. This document
also describes key management requirements for systems implementing
those security mechanisms. This document is not an overall Security
Architecture for the Internet and is instead focused on IP-layer
security. This RFC is the product of the IP Security Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1825.txt"
}

@TECHREPORT{rfc1826,
AUTHOR="R. Atkinson",
TITLE="{IP} Authentication Header",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1826,
PAGES=13,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="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. This RFC is the
product of the IP Security Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1826.txt"
}

@TECHREPORT{rfc1827,
AUTHOR="R. Atkinson",
TITLE="{IP} Encapsulating Security Payload {(ESP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1827,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="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. This RFC
is the product of the IP Security Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1827.txt"
}

@TECHREPORT{rfc1828,
AUTHOR="P. Metzger and W. Simpson",
TITLE="{IP} Authentication using Keyed {MD5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1828,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document describes the use of keyed MD5 with the IP
Authentication Header. This RFC is the product of the IP Security
Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1828.txt"
}

@TECHREPORT{rfc1829,
AUTHOR="P. Karn and P. Metzger and W. Simpson",
TITLE="The {ESP} {DES-CBC} Transform",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1829,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document describes the DES-CBC security transform for the
IP Encapsulating Security Payload (ESP). This RFC is the product of the
IP Security Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1829.txt"
}

@TECHREPORT{rfc1830,
AUTHOR="G. M. Vaudreuil",
TITLE="{SMTP} Service Extensions for Transmission of Large and Binary {MIME}
Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1830,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT={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. This RFC is a
product of the Mail Extensions Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1830.txt"
}

@TECHREPORT{rfc1831,
AUTHOR="R. Srinivasan",
TITLE="{RPC:} Remote Procedure Call Protocol Specification Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1831,
PAGES=18,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT={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{"}. This RFC is the product of the ONC
Remote Procedure Call Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1831.txt"
}

@TECHREPORT{rfc1832,
AUTHOR="R. Srinivasan",
TITLE="{XDR:} External Data Representation Standard",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1832,
PAGES=24,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document describes the External Data Representation
Standard (XDR) protocol as it is currently deployed and accepted. This
RFC is the product of the ONC Remote Procedure Call Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1832.txt"
}

@TECHREPORT{rfc1833,
AUTHOR="R. Srinivasan",
TITLE="Binding Protocols for {ONC} {RPC} Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1833,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document describes the binding protocols used in
conjunction with the ONC Remote Procedure Call (ONC RPC Version 2)
protocols. This RFC is the product of the ONC Remote Procedure Call
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1833.txt"
}

@TECHREPORT{rfc1834,
AUTHOR="J. Gargano and K. H. Weiss",
TITLE="Whois and Network Information Lookup Service, Whois++",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1834,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="As currently defined, NICNAME/WHOIS service is a TCP
transaction based query/response server, running on a few specific
central machines, that provides netwide directory service to Internet
users. The purpose of the Whois and Network Information Lookup Service
Working Group (WNILS) is to expand and define the standard for WHOIS
types of services, to resolve issues associated with the variations in
access and provide a consistent and predictable service across the
network. This memo describes new features for WHOIS to meet these goals.
This RFC is a product of the WNILS Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1834.txt"
}

@TECHREPORT{rfc1835,
AUTHOR="P. Deutsch and R. Schoultz and P. Faltstrom and C. Weider",
TITLE="Architecture of the {WHOIS++} service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1835,
PAGES=41,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document describes WHOIS++, an extension to the trivial
WHOIS service described in RFC 954 to permit WHOIS-like servers to make
available more structured information to the Internet. We describe an
extension to the simple WHOIS data model and query protocol and a
companion extensible, distributed indexing service. A number of options
have also been added such as the use of multiple languages and character
sets, more advanced search expressions, structured data and a number of
other useful features. An optional authentication mechanism for
protecting all or part of the associated WHOIS++ information database
from unauthorized access is also described. This RFC is the product of
the Whois and Network Information Lookup Service Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1835.txt"
}

@TECHREPORT{rfc1836,
AUTHOR="S. E. Kille",
TITLE="Representing the {O/R} Address hierarchy in the {X.500} Directory
Information Tree",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1836,
PAGES=11,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document defines a representation of the O/R Address
hierarchy in the Directory Information Tree. This RFC is a product of
the MHS-DS Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1836.txt"
}

@TECHREPORT{rfc1837,
AUTHOR="S. E. Kille",
TITLE="Representing Tables and Subtrees in the {X.500} Directory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1837,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document defines techniques for representing two types of
information mapping in the OSI Directory. This RFC is the product of the
MHS-DS Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1837.txt"
}

@TECHREPORT{rfc1838,
AUTHOR="S. E. Kille",
TITLE="Use of the {X.500} Directory to support mapping between {X.400} and {RFC}
822 Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1838,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document defines how to use directory to support the
mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327.
This RFC is the product of the MHS-DS Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1838.txt"
}

@TECHREPORT{rfc1841,
AUTHOR="J. Chapman and D. Coli and A. Harvey and B. Jensen and K. Rowett",
TITLE="{PPP} Network Control Protocol for {LAN} Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1841,
PAGES=66,
DAYS=15,
MONTH=sep,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1841.txt"
}

@TECHREPORT{rfc1842,
AUTHOR="Y. Wei and Y. Zhang and J. Li and J. Ding and Y. Jiang",
TITLE="{ASCII} Printable {Characters-Based} Chinese Character Encoding for
Internet Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1842,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT="This document describes the encoding used in electronic mail
and network news messages over the Internet. The 7-bit representation of
GB 2312 Chinese text was specified by Fung Fung Lee of Stanford
University (RFC 1843) and implemented in various software packages under
different platforms. It was further tested and used in the usenet
newsgroups alt.chinese.text and chinese.* as well as various other
network forums with considerable success.",
URL="http://www.rfc-editor.org/rfc/rfc1842.txt"
}

@TECHREPORT{rfc1843,
AUTHOR="F. Lee",
TITLE="{HZ} - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and
{ASCII} characters",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1843,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1995,
ABSTRACT={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{"}.},
URL="http://www.rfc-editor.org/rfc/rfc1843.txt"
}

@TECHREPORT{rfc1845,
AUTHOR="D. H. Crocker and N. Freed and A. Cargille",
TITLE="{SMTP} Service Extension for {Checkpoint/Restart}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1845,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=1995,
ABSTRACT="This memo defines an extension to the SMTP (Simple Mail
Transfer Protocol) 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. This RFC is
the product of the Mail Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1845.txt"
}

@TECHREPORT{rfc1846,
AUTHOR="A. Durand and F. Dupont",
TITLE="{SMTP} 521 Reply Code",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1846,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1995,
ABSTRACT="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. This RFC is the product of the Mail
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1846.txt"
}

@TECHREPORT{rfc1847,
AUTHOR="J. Galvin and S. Murphy and S. D. Crocker and N. Freed",
TITLE="Security Multiparts for {MIME:} {Multipart/Signed} and
{Multipart/Encrypted}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1847,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT={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. This RFC is the product of the Privacy-Enhanced
Electronic Mail Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1847.txt"
}

@TECHREPORT{rfc1848,
AUTHOR="S. D. Crocker and N. Freed and J. Galvin and S. Murphy",
TITLE="{MIME} Object Security Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1848,
PAGES=48,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="This document defines MIME Object Security Services (MOSS), a
protocol that uses the multipart/signed and multipart/encrypted
framework to 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. This RFC is the product of the Privacy-Enhanced Electronic
Mail Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1848.txt"
}

@TECHREPORT{rfc1850,
AUTHOR="F. Baker and R. Coltun",
TITLE="{OSPF} Version 2 Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1850,
PAGES=80,
DAYS=15,
MONTH=nov,
YEAR=1995,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the Open
Shortest Path First Routing Protocol. This RFC is a product of the Open
Shortest Path First IGP Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1850.txt"
}

@TECHREPORT{rfc1851,
AUTHOR="P. Karn and P. Metzger and W. Simpson",
TITLE="The {ESP} Triple {DES} Transform",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1851,
PAGES=11,
DAYS=15,
MONTH=sep,
YEAR=1995,
ABSTRACT="This document describes the Triple DES-CBC security transform
for the IP Encapsulating Security Payload (ESP).",
URL="http://www.rfc-editor.org/rfc/rfc1851.txt"
}

@TECHREPORT{rfc1852,
AUTHOR="P. Metzger and W. Simpson",
TITLE="{IP} Authentication using Keyed {SHA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1852,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1995,
ABSTRACT="This document describes the use of keyed SHA with the IP
Authentication Header.",
URL="http://www.rfc-editor.org/rfc/rfc1852.txt"
}

@TECHREPORT{rfc1853,
AUTHOR="W. Simpson",
TITLE="{IP} in {IP} Tunneling",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1853,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="This document discusses implementation techniques for using IP
Protocol/Payload number 4 Encapsulation for tunneling with IP Security
and other protocols.",
URL="http://www.rfc-editor.org/rfc/rfc1853.txt"
}

@TECHREPORT{rfc1854,
AUTHOR="N. Freed",
TITLE="{SMTP} Service Extension for Command Pipelining",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1854,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="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. This RFC is the product of the Mail Extensions Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1854.txt"
}

@TECHREPORT{rfc1855,
AUTHOR="S. Hambridge",
TITLE="Netiquette Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1855,
PAGES=21,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1855.txt"
}

@TECHREPORT{rfc1856,
AUTHOR="H. Clark",
TITLE="The Opstat {Client-Server} Model for Statistics Retrieval",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1856,
PAGES=17,
DAYS=15,
MONTH=sep,
YEAR=1995,
ABSTRACT="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. This document is the
product of the Operational Statistics Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1856.txt"
}

@TECHREPORT{rfc1857,
AUTHOR="M. Lambert",
TITLE="A Model for Common Operational Statistics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1857,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="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. This document is the product of the
Operational Statistics Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1857.txt"
}

@TECHREPORT{rfc1858,
AUTHOR="G. Ziemba and D. P. Reed and P. Traina",
TITLE="Security Considerations for {IP} Fragment Filtering",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1858,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1858.txt"
}

@TECHREPORT{rfc1859,
AUTHOR="Y. Pouffary",
TITLE="{ISO} Transport Class 2 Non-use of Explicit Flow Control over {TCP}
{RFC1006} extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1859,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="This document is an extension to STD35, RFC1006, a standard
for the Internet community. The document does not duplicate the protocol
definitions contained in RFC1006 and in International Standard ISO 8073.
It supplements that information with the description of how to implement
ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP.
The document should be used in conjunction with the RFC1006 and ISO
8073.",
URL="http://www.rfc-editor.org/rfc/rfc1859.txt"
}

@TECHREPORT{rfc1860,
AUTHOR="T. Pummill and B. Manning",
TITLE="Variable Length Subnet Table For {IPv4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1860,
PAGES=3,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1860.txt"
}

@TECHREPORT{rfc1861,
AUTHOR="A. Gwinn",
TITLE="Simple Network Paging Protocol - Version 3 {-Two-Way} Enhanced",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1861,
PAGES=23,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT={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).},
URL="http://www.rfc-editor.org/rfc/rfc1861.txt"
}

@TECHREPORT{rfc1862,
AUTHOR="M. McCahill and J. L. Romkey and M. Schwartz and K. Sollins and T.
Verschuren and C. Weider",
TITLE="Report of the {IAB} Workshop on Internet Information Infrastructure,
October {12-14,} 1994",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1862,
PAGES=27,
DAYS=15,
MONTH=nov,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1862.txt"
}

@TECHREPORT{rfc1863,
AUTHOR="D. Haskin",
TITLE="A {BGP/IDRP} Route Server alternative to a full mesh routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1863,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="This document describes the use and detailed design of Route
Servers for dissemination of routing information among BGP/IDRP speaking
routers. 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). This RFC is a product of the Inter-Domain Routing Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1863.txt"
}

@TECHREPORT{rfc1864,
AUTHOR="J. Myers and M. P. Rose",
TITLE="The {Content-MD5} Header Field",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1864,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1995,
ABSTRACT="This memo specifies an optional header field, Content-MD5, for
use with MIME-conformant messages. This RFC is the product of the
Internet Messages Extension Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1864.txt"
}

@TECHREPORT{rfc1866,
AUTHOR="T. Berners-Lee and D. Connolly",
TITLE="Hypertext Markup Language - {2.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1866,
PAGES=77,
DAYS=15,
MONTH=nov,
YEAR=1995,
ABSTRACT={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. 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). The {"}text/html{"} Internet Media Type (RFC 1590) and MIME Content
Type (RFC 1521) is defined by this specification. This RFC is the
product of the HyperText Markup Language Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1866.txt"
}

@TECHREPORT{rfc1867,
AUTHOR="E. Nebel and L. Masinter",
TITLE="Form-based File Upload in {HTML}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1867,
PAGES=13,
DAYS=15,
MONTH=nov,
YEAR=1995,
ABSTRACT="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. The proposal is independent of which version of HTML it becomes
a part. This RFC is the product of the HyperText Markup Language Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1867.txt"
}

@TECHREPORT{rfc1868,
AUTHOR="G. Malkin",
TITLE="{ARP} Extension - {UNARP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1868,
PAGES=4,
DAYS=15,
MONTH=nov,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1868.txt"
}

@TECHREPORT{rfc1869,
AUTHOR="J. Klensin and N. Freed and M. P. Rose and E. Stefferud and D. H. Crocker",
TITLE="{SMTP} Service Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1869,
PAGES=11,
DAYS=15,
MONTH=nov,
YEAR=1995,
ABSTRACT="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. This RFC is the product of
the Internet Mail Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1869.txt"
}

@TECHREPORT{rfc1870,
AUTHOR="J. Klensin and N. Freed and K. Moore",
TITLE="{SMTP} Service Extension for Message Size Declaration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1870,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=1995,
ABSTRACT="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. This RFC is the product of the Internet
Mail Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1870.txt"
}

@TECHREPORT{rfc1871,
AUTHOR="J. B. Postel",
TITLE="Addendum to {RFC} 1602 {--} Variance Procedure",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1871,
PAGES=4,
DAYS=15,
MONTH=nov,
YEAR=1995,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1871.txt"
}

@TECHREPORT{rfc1872,
AUTHOR="E. Levinson",
TITLE="The {MIME} {Multipart/Related} Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1872,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="The Multipart/Related content-type provides a common mechanism
for representing objects that are aggregates of related MIME
(Multipurpose Internet Mail Extensions) body parts. This document
defines the Multipart/Related content-type and provides examples of its
use. This RFC is the product of the MIME Content-Type for SGML Documents
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1872.txt"
}

@TECHREPORT{rfc1873,
AUTHOR="E. Levinson",
TITLE="{Message/External-Body} {Content-ID} Access Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1873,
PAGES=4,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="When using MIME (Multipurpose Internet Mail Extensions) to
encapsulate a structured object that consist of many elements, for
example an SGML document, 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. 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. This RFC is the
product of the MIME Content-Type for SGML Documents Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1873.txt"
}

@TECHREPORT{rfc1874,
AUTHOR="E. Levinson",
TITLE="{SGML} Media Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1874,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="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. This RFC is the product of the MIME
Content-Type for SGML Documents Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1874.txt"
}

@TECHREPORT{rfc1875,
AUTHOR="N. Berge",
TITLE="{UNINETT} {PCA} Policy Statements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1875,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="This document provides information about policy statements
submitted by the UNINETT Policy Certification Authority (UNINETT PCA).
It's purpose is to provide information to members of the Internet
community who wish to evaluate the trust they can place in a
certification path that includes a certificate issued by the UNINETT
PCA, or to set up a CA to be certified by the UNINETT PCA.",
URL="http://www.rfc-editor.org/rfc/rfc1875.txt"
}

@TECHREPORT{rfc1877,
AUTHOR="S. Cobb",
TITLE="{PPP} Internet Protocol Control Protocol Extensions for Name Server
Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1877,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1877.txt"
}

@TECHREPORT{rfc1881,
AUTHOR="Anton Riabov and  Iesg",
TITLE="{IPv6} Address Allocation Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1881,
PAGES=2,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="The IPv6 address space will be managed by the IANA (Internet
Assigned Numbers Authority) for the good of the Internet community, with
advice from the IAB and the IESG, by delegation to the regional
registries.",
URL="http://www.rfc-editor.org/rfc/rfc1881.txt"
}

@TECHREPORT{rfc1882,
AUTHOR="B. Hancock",
TITLE="The 12-Days of Technology Before Christmas",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1882,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="A poem.",
URL="http://www.rfc-editor.org/rfc/rfc1882.txt"
}

@TECHREPORT{rfc1883,
AUTHOR="S. E. Deering and R. Hinden",
TITLE="Internet Protocol, Version 6 {(IPv6)} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1883,
PAGES=37,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="This document specifies version 6 of the Internet Protocol
(IPv6), also sometimes referred to as IP Next Generation or IPng. This
document is the product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1883.txt"
}

@TECHREPORT{rfc1884,
AUTHOR="R. Hinden and S. E. Deering and Edson Ursini",
TITLE="{IP} Version 6 Addressing Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1884,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="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. This document is the product of the IPNG Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1884.txt"
}

@TECHREPORT{rfc1885,
AUTHOR="A. Conta and S. E. Deering",
TITLE="Internet Control Message Protocol {(ICMPv6)} for the Internet Protocol
Version 6 {(IPv6)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1885,
PAGES=20,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="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. This document is the product of the IPNG
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1885.txt"
}

@TECHREPORT{rfc1886,
AUTHOR="S. Thomson and C. Huitema",
TITLE="{DNS} Extensions to support {IP} version 6",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1886,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="This document defines the changes that need to be made to the
Domain Name System (DNS) to support hosts running IP version 6 (IPv6).
The changes include a 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. This document is the product of the IPNG
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1886.txt"
}

@TECHREPORT{rfc1887,
EDITOR="Y. Rekhter and T. Li",
TITLE="An Architecture for {IPv6} Unicast Address Allocation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1887,
PAGES=26,
DAYS=15,
MONTH=dec,
YEAR=1995,
ABSTRACT="This document provides an architecture for allocating IPv6
unicast addresses in the Internet. The overall IPv6 addressing
architecture is defined in RFC 1884. This document does not go into the
details of an addressing plan. This document is the product of the IPNG
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1887.txt"
}

@TECHREPORT{rfc1865,
AUTHOR="W. Houser and J. Griffin and C. Hage",
TITLE="{EDI} Meets the Internet Frequently Asked Questions about Electronic Data
Interchange {(EDI)} on the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1865,
PAGES=41,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1865.txt"
}

@TECHREPORT{rfc1876,
AUTHOR="C. K. Davis and P. Vixie and T. Goodwin and I. Dickinson",
TITLE="A Means for Expressing Location Information in the Domain Name System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1876,
PAGES=18,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1876.txt"
}

@TECHREPORT{rfc1879,
EDITOR="B. Manning",
TITLE="Class A Subnet Experiment Results and Recommendations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1879,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="This memo documents some experiences with the RFC 1797 subnet
A experiment (performed by the Net39 Test Group (see credits)) and
provides a number of recommendations on future direction for both the
Internet Registries and the Operations community.",
URL="http://www.rfc-editor.org/rfc/rfc1879.txt"
}

@TECHREPORT{rfc1888,
AUTHOR="J. Bound and B. E. Carpenter and D. Harrington and J. Houldsworth and A.
Lloyd",
TITLE="{OSI} {NSAPs} and {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1888,
PAGES=16,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. This RFC is the product of the IPNG Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1888.txt"
}

@TECHREPORT{rfc1889,
AUTHOR="Henning Schulzrinne and S. Casner and R. Frederick and V. Jacobson",
TITLE="{RTP:} A Transport Protocol for {Real-Time} Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1889,
PAGES=75,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="This memo 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. This RFC is the product of the Audio/Video Transport Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1889.txt"
}

@TECHREPORT{rfc1890,
AUTHOR="Henning Schulzrinne",
TITLE="{RTP} Profile for Audio and Video Conferences with Minimal Control",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1890,
PAGES=18,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="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. 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. This RFC is
the product of the Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1890.txt"
}

@TECHREPORT{rfc1891,
AUTHOR="K. Moore",
TITLE="{SMTP} Service Extension for Delivery Status Notifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1891,
PAGES=31,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="This memo defines an extension to the SMTP (Simple Mail
Transfer Protocol) 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. This RFC is the product of the Notifications and
Acknowledgements Requirements Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1891.txt"
}

@TECHREPORT{rfc1892,
AUTHOR="G. M. Vaudreuil",
TITLE="The {Multipart/Report} Content Type for the Reporting of Mail System
Administrative Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1892,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="This memo defines the Multipart/Report MIME content-type for
the reporting of mail system administrative messages. This RFC is the
product of the Notifications and Acknowledgements Requirements Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1892.txt"
}

@TECHREPORT{rfc1893,
AUTHOR="G. M. Vaudreuil",
TITLE="Enhanced Mail System Status Codes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1893,
PAGES=15,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="There currently is not a standard mechanism for the reporting
of mail system errors except for the limited set offered by SMTP (Simple
Mail Transfer Protocol0 and the system specific text descriptions sent
in mail messages. There is a pressing need for a rich machine readable
status code for use in delivery status notifications (DSN). This
document proposes a new set of status codes for this purpose. This RFC
is the product of the Notifications and Acknowledgements Requirements
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1893.txt"
}

@TECHREPORT{rfc1894,
AUTHOR="K. Moore and G. M. Vaudreuil",
TITLE="An Extensible Message Format for Delivery Status Notifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1894,
PAGES=39,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="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. This RFC is the product of the Notifications
and Acknowledgements Requirements Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1894.txt"
}

@TECHREPORT{rfc1895,
AUTHOR="E. Levinson",
TITLE="The {Application/CALS-1840} Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1895,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1895.txt"
}

@TECHREPORT{rfc1896,
AUTHOR="Paul  Resnick and A. J. Walker",
TITLE="The text/enriched {MIME} Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1896,
PAGES=21,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="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
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 in RFC 1523 and
RFC 1563, and is only intended to be used in the short term until other
MIME types for text formatting in Internet mail are developed and
deployed.",
URL="http://www.rfc-editor.org/rfc/rfc1896.txt"
}

@TECHREPORT{rfc1897,
AUTHOR="R. Hinden and J. B. Postel",
TITLE="{IPv6} Testing Address Allocation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1897,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="This document describes an allocation plan for IPv6 addresses
to be used in testing IPv6 prototype software. These addresses are
temporary and will be reclaimed in the future. Any IPv6 system using
these addresses will have to renumber at some time in the future. These
addresses will not to be routable in the Internet other than for IPv6
testing. This RFC is the product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1897.txt"
}

@TECHREPORT{rfc1898,
AUTHOR="D. Eastlake 3rd and B. Boesch and S. D. Crocker and M. Yesil",
TITLE="{CyberCash} Credit Card Protocol Version {0.8}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1898,
PAGES=52,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1898.txt"
}

@TECHREPORT{rfc1900,
AUTHOR="B. E. Carpenter and Y. Rekhter",
TITLE="Renumbering Needs Work",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1900,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1900.txt"
}

@TECHREPORT{rfc1901,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Introduction to Community-based {SNMPv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1901,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="The purpose of this document is to define the Community-based
Administrative Framework for the SNMP version 2 framework (SNMPv2). The
SNMPv2 framework is fully described in RFCs 1902, 1903, 1904, 1905,
1906, and 1907. This RFC is the product of the SNMP Version 2 Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1901.txt"
}

@TECHREPORT{rfc1902,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Structure of Management Information for Version 2 of the Simple Network
Management Protocol {(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1902,
PAGES=40,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="A management system contains: several (potentially many)
nodes, each with a processing entity, termed an agent, which has access
to management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and management stations. Operations of the protocol are carried
out under an administrative framework which defines authentication,
authorization, access control, and privacy policies. Management stations
execute management applications which monitor and control managed
elements. Managed elements are devices such as hosts, routers, terminal
servers, etc., which are monitored and controlled via access to their
management information. Management information is viewed as a collection
of managed objects, residing in a virtual information store, termed the
Management Information Base (MIB). Collections of related objects are
defined in MIB modules. These modules are written using an adapted
subset of OSI's Abstract Syntax Notation One (ASN.1). It is the purpose
of this document, the Structure of Management Information (SMI), to
define that adapted subset, and to assign a set of associated
administrative values. The SMI is divided into three parts: module
definitions, object definitions, and, notification definitions. This RFC
is the product of the SNMP Version 2 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1902.txt"
}

@TECHREPORT{rfc1903,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Textual Conventions for Version 2 of the Simple Network Management Protocol
{(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1903,
PAGES=23,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="When designing a MIB module, it is often useful to define new
types similar to those defined in the SMI. In comparison to a type
defined in the SMI, each of these new types has a different name, a
similar syntax, but a more precise semantics. These newly defined types
are termed textual conventions, and are used for the convenience of
humans reading the MIB module. It is the purpose of this document to
define the initial set of textual conventions available to all MIB
modules. This RFC is the product of the SNMP Version 2 Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1903.txt"
}

@TECHREPORT{rfc1904,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Conformance Statements for Version 2 of the Simple Network Management
Protocol {(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1904,
PAGES=24,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined in
MIB modules. These modules are written using a subset of OSI's Abstract
Syntax Notation One (ASN.1), termed the Structure of Management
Information (SMI). It may be useful to define the acceptable
lower-bounds of implementation, along with the actual level of
implementation achieved. It is the purpose of this document to define
the notation used for these purposes. This RFC is the product of the
SNMP Version 2 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1904.txt"
}

@TECHREPORT{rfc1905,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Protocol Operations for Version 2 of the Simple Network Management Protocol
{(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1905,
PAGES=24,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT={The management protocol, version 2 of the Simple Network
Management Protocol, provides for the exchange of messages which convey
management information between the agents and the management stations.
The form of these messages is a message {"}wrapper{"} which encapsulates a
Protocol Data Unit (PDU). The form and meaning of the {"}wrapper{"} is
determined by an administrative framework which defines both
authentication and authorization policies. It is the purpose of this
document to define the operations of the protocol with respect to the
sending and receiving of the PDUs. This RFC is the product of the SNMP
Version 2 Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1905.txt"
}

@TECHREPORT{rfc1906,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Transport Mappings for Version 2 of the Simple Network Management Protocol
{(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1906,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="The management protocol, version 2 of the Simple Network
Management Protocol (SNMPv2), may be used over a variety of protocol
suites. It is the purpose of this document to define how the SNMPv2 maps
onto an initial set of transport domains. Other mappings may be defined
in the future. Although several mappings are defined, the mapping onto
UDP is the preferred mapping. As such, to provide for the greatest level
of interoperability, systems which choose to deploy other mappings
should also provide for proxy service to the UDP mapping. This RFC is
the product of the SNMP Version 2 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1906.txt"
}

@TECHREPORT{rfc1907,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Management Information Base for Version 2 of the Simple Network Management
Protocol {(SNMPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1907,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="The management protocol, version 2 of the Simple Network
Management Protocol (SNMPv2), provides for the exchange of messages
which convey management information between the agents and the
management stations. It is the purpose of this document to define
managed objects which describe the behavior of a SNMPv2 entity. This RFC
is the product of the SNMP Version 2 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1907.txt"
}

@TECHREPORT{rfc1908,
AUTHOR="J. D. Case and K. McCloghrie and M. P. Rose and S. Waldbusser",
TITLE="Coexistence between Version 1 and Version 2 of the Internet-standard
Network Management Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1908,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1996,
ABSTRACT="The purpose of this document is to describe coexistence
between version 2 of the Internet-standard Network Management Framework,
termed the SNMP version 2 framework (SNMPv2), and the original
Internet-standard Network Management Framework (SNMPv1). This RFC is the
product of the SNMP Version 2 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1908.txt"
}

@TECHREPORT{rfc1909,
EDITOR="K. McCloghrie",
TITLE="An Administrative Infrastructure for {SNMPv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1909,
PAGES=19,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="A management system contains: several (potentially many)
nodes, each with a processing entity, termed an agent, which has access
to management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the
agents and management stations. Operations of the protocol are carried
out under an administrative framework which defines authentication,
authorization, access control, and privacy policies. Management stations
execute management applications which monitor and control managed
elements. Managed elements are devices such as hosts, routers, terminal
servers, etc., which are monitored and controlled via access to their
management information. It is the purpose of this RFC to define an
administrative framework which realizes effective management in a
variety of configurations and environments.",
URL="http://www.rfc-editor.org/rfc/rfc1909.txt"
}

@TECHREPORT{rfc1910,
EDITOR="G. Waters",
TITLE="User-based Security Model for {SNMPv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1910,
PAGES=44,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="The Administrative Infrastructure for SNMPv2 document (RFC
1909), defines an administrative framework which realizes effective
management in a variety of configurations and environments. In this
administrative framework, a security model defines the mechanisms used
to achieve an administratively-defined level of security for protocol
interactions. Although many such security models might be defined, it is
the purpose of this RFC, User-based Security Model for SNMPv2, to define
the first, and, as of this writing, only, security model for this
administrative framework.",
URL="http://www.rfc-editor.org/rfc/rfc1910.txt"
}

@TECHREPORT{rfc1911,
AUTHOR="G. M. Vaudreuil",
TITLE="Voice Profile for Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1911,
PAGES=22,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="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. This RFC is a profile of the Internet standard MIME and ESMTP
protocols for use as a digital voice networking protocol. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1911.txt"
}

@TECHREPORT{rfc1912,
AUTHOR="D. Barr",
TITLE="Common {DNS} Operational and Configuration Errors",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1912,
PAGES=16,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="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 RFC 1537.",
URL="http://www.rfc-editor.org/rfc/rfc1912.txt"
}

@TECHREPORT{rfc1913,
AUTHOR="C. Weider and J. Fullton and S. Spero",
TITLE="Architecture of the Whois++ Index Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1913,
PAGES=16,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="The WHOIS++ directory service is intended to provide a simple,
extensible directory service predicated on a template-based information
model and a flexible query language. This RFC describes a general
architecture designed for indexing distributed databases, and then
applys that architecture to link together many of these WHOIS++ servers
into a distributed, searchable wide area directory service. This RFC is
the product of the Whois and Network Information Lookup Service Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1913.txt"
}

@TECHREPORT{rfc1914,
AUTHOR="P. Faltstrom and R. Schoultz and C. Weider",
TITLE="How to Interact with a Whois++ Mesh",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1914,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="In the Whois++ architecture, mesh traversal is done by the
client, since each server 'refers' the client to the next appropriate
server(s). The protocol is simple. The client opens a connection to a
server, sends a query, receives a reply, closes the connection, and
after parsing the response the client decides which server to contact
next, if necessary. So, the client needs to have an algorithm to follow
when it interacts with the Whois++ mesh so that referral loops can be
detected, cost is minimised, and appropriate servers are rapidly and
effectively contacted. This RFC is the product of the Whois and Network
Information Lookup Service Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1914.txt"
}

@TECHREPORT{rfc1915,
AUTHOR="F. Kastenholz",
TITLE="Variance for The {PPP} Compression Control Protocol and The {PPP}
Encryption Control Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1915,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="This variance procedure will allow the PPP Connection Control
Protocol (CCP) and the PPP Encryption Control Protocol (ECP) to proceed
as standards track documents without getting the necessary licenses as
required by RFC 1602. The Variance presents this information in detail.
This RFC is the product of the CIDR Deployment Practices Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1915.txt"
}

@TECHREPORT{rfc1916,
AUTHOR="H. Berkowitz and P. Ferguson and Will E Leland and P. Nesser",
TITLE="Enterprise Renumbering: Experience and Information Solicitation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1916,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="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.
This RFC is the product of the Procedures for Internet/Enterprise
Renumbering Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1916.txt"
}

@TECHREPORT{rfc1917,
AUTHOR="P. Nesser",
TITLE="An Appeal to the Internet Community to Return Unused {IP} Networks
(Prefixes) to the {IANA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1917,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="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. This RFC is the product
of the CIDR Deployment Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1917.txt"
}

@TECHREPORT{rfc1918,
AUTHOR="Y. Rekhter and B. Moskowitz and D. Karrenberg and G. J. de and E. Lear",
TITLE="Address Allocation for Private Internets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1918,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=1996,
ABSTRACT="For the purposes of this document, an enterprise is an entity
autonomously operating a network using TCP/IP and in particular
determining the addressing plan and address assignments within that
network. This document describes address allocation for private
internets. The allocation permits full network layer connectivity among
all hosts inside an enterprise as well as among all public hosts of
different enterprises. The cost of using private internet address space
is the potentially costly effort to renumber hosts and networks between
public and private. This RFC is the product of the CIDR Deployment
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1918.txt"
}

@TECHREPORT{rfc1919,
AUTHOR="M. Chatel",
TITLE="Classical versus Transparent {IP} Proxies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1919,
PAGES=35,
DAYS=15,
MONTH=mar,
YEAR=1996,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1919.txt"
}

@TECHREPORT{rfc1920,
AUTHOR="J. B. Postel",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1920,
PAGES=40,
DAYS=15,
MONTH=mar,
YEAR=1996,
ABSTRACT="This memo describes the state of standardization of protocols
used in the Internet as determined by the Internet Architecture Board
(IAB). This memo is an Internet Standard. Distribution of this memo is
unlimited.",
URL="http://www.rfc-editor.org/rfc/rfc1920.txt"
}

@TECHREPORT{rfc1921,
AUTHOR="J. Dujonc",
TITLE="{TNVIP} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1921,
PAGES=30,
DAYS=15,
MONTH=mar,
YEAR=1996,
ABSTRACT="This document specifies a Telnet profile to support VIP
terminal emulation allowing the access to the BULL hosts applications
through a TCP/IP network.",
URL="http://www.rfc-editor.org/rfc/rfc1921.txt"
}

@TECHREPORT{rfc1922,
AUTHOR="Hf. Zhu and Dy. Hu and Zg. Wang and Tc. Kao and Wch. Chang and M. R.
Crispin",
TITLE="Chinese Character Encoding for Internet Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1922,
PAGES=27,
DAYS=15,
MONTH=mar,
YEAR=1996,
ABSTRACT="This memo describes methods of transporting Chinese characters
in Internet services which transport text, such as electronic mail (RFC
822), network news (RFC 1036), telnet (RFC 854) and the World Wide Web
(RFC 1866).",
URL="http://www.rfc-editor.org/rfc/rfc1922.txt"
}

@TECHREPORT{rfc1923,
AUTHOR="J. Y. Halpern and S. Bradner",
TITLE="{RIPv1} Applicability Statement for Historic Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1923,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1996,
ABSTRACT="RIP Version 1 (RFC 1058) has 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. This RFC is the product of the Routing
Area Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1923.txt"
}

@TECHREPORT{rfc1924,
AUTHOR="R. Elz",
TITLE="A Compact Representation of {IPv6} Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1924,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1924.txt"
}

@TECHREPORT{rfc1925,
AUTHOR="R. Callon",
TITLE="The Twelve Networking Truths",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1925,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1925.txt"
}

@TECHREPORT{rfc1926,
AUTHOR="J. Eriksson",
TITLE="An Experimental Encapsulation of {IP} Datagrams on Top of {ATM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1926,
PAGES=2,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1926.txt"
}

@TECHREPORT{rfc1927,
AUTHOR="C. Rogers",
TITLE="Suggested Additional {MIME} Types for Associating Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1927,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="This memo suggests additional MIME Types for associating
documents. This memo provides information for the Internet community.
This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.",
URL="http://www.rfc-editor.org/rfc/rfc1927.txt"
}

@TECHREPORT{rfc1928,
AUTHOR="M. Leech and M. Ganis and Y. Lee and R. Kuris and D. Koblas and L. Jones",
TITLE="{SOCKS} Protocol Version 5",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1928,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1996,
ABSTRACT="This memo describes a protocol that is an evolution of the
previous version of the protocol, version 4. This new protocol stems
from active discussions and prototype implementations. This RFC is a
product of the Authenticated Firewall Traversal Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1928.txt"
}

@TECHREPORT{rfc1929,
AUTHOR="M. Leech",
TITLE="{Username/Password} Authentication for {SOCKS} {V5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1929,
PAGES=2,
DAYS=15,
MONTH=mar,
YEAR=1996,
ABSTRACT={The protocol specification for SOCKS Version 5 specifies a
generalized framework for the use of arbitrary authentication protocols
in the initial socks connection setup. This document describes one of
those protocols, as it fits into the SOCKS Version 5 authentication
{"}subnegotiation{"}. This RFC is the product of the Authenticated Firewall
Traversal Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1929.txt"
}

@TECHREPORT{rfc1930,
AUTHOR="J. Hawkinson and T. Bates",
TITLE="Guidelines for creation, selection, and registration of an Autonomous
System {(AS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1930,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1996,
ABSTRACT="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 EGP), BGP (Border Gateway
Protocol, the current de facto standard for inter-AS routing, and IDRP
(The OSI Inter-Domain Routing Protocol, which the Internet is expected
to adopt when BGP becomes obsolete. It should be noted that the IDRP
equivalent of an AS is the RDI, or Routing Domain Identifier. This RFC
is the product of the Inter-Domain Routing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1930.txt"
}

@TECHREPORT{rfc1931,
AUTHOR="D. Brownell",
TITLE="Dynamic {RARP} Extensions for Automatic Network Address Acquisition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1931,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="This memo is being published to historically document this
protocol for the record. This memo describes extensions to the Reverse
Address Resolution Protocol and called Dynamic RARP (DRARP, pronounced
D-RARP). The role of DRARP, and to some extent the configuration
protocol used in conjunction with it, has subsequently been addressed by
the DHCP protocol.",
URL="http://www.rfc-editor.org/rfc/rfc1931.txt"
}

@TECHREPORT{rfc1932,
AUTHOR="R. Cole and D. H. Shur and C. Villamizar",
TITLE="{IP} over {ATM:} A Framework Document",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1932,
PAGES=31,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="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. This RFC
is the product of the IP Over Asynchronous Transfer Mode Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1932.txt"
}

@TECHREPORT{rfc1933,
AUTHOR="R. Gilligan and E. Nordmark",
TITLE="Transition Mechanisms for {IPv6} Hosts and Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1933,
PAGES=22,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="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. This RFC is the product of
the New Generation Transition Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1933.txt"
}

@TECHREPORT{rfc1934,
AUTHOR="K. L. Smith",
TITLE="Ascend's Multilink Protocol Plus {(MP+)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1934,
PAGES=47,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1934.txt"
}

@TECHREPORT{rfc1935,
AUTHOR="J. S. Quarterman and S. Carl-Mitchell",
TITLE="What is the Internet, Anyway?",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1935,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="We often mention the Internet, and in the press you read about
the Internet as the prototype of the Information Highway; as a research
tool; as open for business; as not ready for prime time; as a place your
children might communicate with (pick one) a. strangers, b. teachers, c.
pornographers, d. other children, e. their parents; as bigger than
Poland; as smaller than Chicago; as a place to surf; as the biggest hype
since Woodstock; as a competitive business tool; as the newest thing
since sliced bread. What is the Internet, anyway?",
URL="http://www.rfc-editor.org/rfc/rfc1935.txt"
}

@TECHREPORT{rfc1936,
AUTHOR="J. Touch and B. Parham",
TITLE="Implementing the Internet Checksum in Hardware",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1936,
PAGES=21,
DAYS=15,
MONTH=apr,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1936.txt"
}

@TECHREPORT{rfc1937,
AUTHOR="Y. Rekhter and D. Kandlur",
TITLE={{{"}Local/Remote{"}} Forwarding Decision in Switched Data Link Subnetworks},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1937,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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. This RFC is the product of the Routing over Large Clouds
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1937.txt"
}

@TECHREPORT{rfc1938,
AUTHOR="N. Haller and C. Metz",
TITLE="A {One-Time} Password System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1938,
PAGES=18,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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 One-Time Password System that was released by
Bellcore and is described in references. This RFC is the product of the
One Time Password Authentication Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1938.txt"
}

@TECHREPORT{rfc1939,
AUTHOR="J. Myers and M. P. Rose",
TITLE="Post Office Protocol - Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1939,
PAGES=23,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT={On certain types of smaller nodes in the Internet it is often
impractical to maintain a message transport system (MTS). For example, a
workstation may not have sufficient resources (cycles, disk space) in
order to permit a SMTP server (RFC 821) and associated local mail
delivery system to be kept resident and continuously running. Similarly,
it may be expensive (or impossible) to keep a personal computer
interconnected to an IP-style network for long amounts of time (the node
is lacking the resource known as {"}connectivity{"}). Despite this, it is
often very useful to be able to manage mail on these smaller nodes, and
they often support a user agent (UA) to aid the tasks of mail handling.
To solve this problem, a node which can support an MTS entity offers a
maildrop service to these less endowed nodes. The Post Office Protocol -
Version 3 (POP3) is intended to permit a workstation to dynamically
access a maildrop on a server host in a useful fashion. Usually, this
means that the POP3 protocol is used to allow a workstation to retrieve
mail that the server is holding for it.},
URL="http://www.rfc-editor.org/rfc/rfc1939.txt"
}

@TECHREPORT{rfc1940,
AUTHOR="D. Estrin and T. Li and Y. Rekhter and K. Varadhan and D. Zappala",
TITLE="Source Demand Routing: Packet Format and Forwarding Specification (Version
{1)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1940,
PAGES=27,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT={The purpose of SDRP (Source Demand Routing) is to support
source-initiated selection of routes to complement the route selection
provided by existing routing protocols for both inter-domain and
intra-domain routes. This document refers to such source-initiated
routes as {"}SDRP routes{"}. This document describes the packet format and
forwarding procedure for SDRP. It also describes procedures for
ascertaining feasibility of SDRP routes. Other components not described
here are routing information distribution and route computation. This
portion of the protocol may initially be used with manually configured
routes. The same packet format and processing will be usable with
dynamic route information distribution and computation methods under
development. This RFC is the product of the Source Demand Routing
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1940.txt"
}

@TECHREPORT{rfc1941,
AUTHOR="J. Sellers and J. Robichaux",
TITLE="Frequently Asked Questions for Schools",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1941,
PAGES=70,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="The goal of this FYI document 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. This RFC is
the product of the Internet School Networking Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1941.txt"
}

@TECHREPORT{rfc1942,
AUTHOR="D. Raggett",
TITLE="{HTML} Tables",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1942,
PAGES=30,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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 extends 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. This RFC is the product of the
Hypertext Markup Language Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1942.txt"
}

@TECHREPORT{rfc1943,
AUTHOR="B. Jennings",
TITLE="Building an {X.500} Directory Service in the {US}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1943,
PAGES=22,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1943.txt"
}

@TECHREPORT{rfc1944,
AUTHOR="S. Bradner and J. McQuaid",
TITLE="Benchmarking Methodology for Network Interconnect Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1944,
PAGES=30,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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. This RFC
is the product of the Benchmarking Methodology Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1944.txt"
}

@TECHREPORT{rfc1945,
AUTHOR="T. Berners-Lee and R. Fielding and H. Frystyk",
TITLE="Hypertext Transfer Protocol {--} {HTTP/1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1945,
PAGES=60,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT={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. 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{"}. This RFC is the product of the HyperText Transfer Protocol
Working Group of the IETF. IESG Note: The IESG has concerns about this
protocol, and expects this document to be replaced relatively soon by a
standards track document.},
URL="http://www.rfc-editor.org/rfc/rfc1945.txt"
}

@TECHREPORT{rfc1946,
AUTHOR="S. Jackowski",
TITLE="Native {ATM} Support for {ST2+}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1946,
PAGES=21,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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).
This memo describes a working implementation which enables applications
to directly invoke ATM services in the following environments: ATM to
internet, internet to ATM, and internet to internet across ATM.",
URL="http://www.rfc-editor.org/rfc/rfc1946.txt"
}

@TECHREPORT{rfc1947,
AUTHOR="D. Spinellis",
TITLE="Greek Character Encoding for Electronic Mail Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1947,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT={This document describes a standard encoding for electronic
mail containing Greek text and provides implementation guide-lines. The
standard is based on MIME and the ISO 8859-7 character encoding.
Although the implementation of this standard is straightforward several
non-standard but {"}functional{"} - though unlikely to inter-operate -
alternatives are in common use. For this reason we highlight common
implementation and mail user agent setup errors.},
URL="http://www.rfc-editor.org/rfc/rfc1947.txt"
}

@TECHREPORT{rfc1948,
AUTHOR="S. M. Bellovin",
TITLE="Defending Against Sequence Number Attacks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1948,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1948.txt"
}

@TECHREPORT{rfc1949,
AUTHOR="A. Ballardie",
TITLE="Scalable Multicast Key Distribution",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1949,
PAGES=18,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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. 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. This memo provides a scalable solution to the
multicast key distribution problem.",
URL="http://www.rfc-editor.org/rfc/rfc1949.txt"
}

@TECHREPORT{rfc1950,
AUTHOR="P. Deutsch and J-l. Gailly",
TITLE="{ZLIB} Compressed Data Format Specification version {3.3}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1950,
PAGES=11,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1950.txt"
}

@TECHREPORT{rfc1951,
AUTHOR="P. Deutsch",
TITLE="{DEFLATE} Compressed Data Format Specification version {1.3}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1951,
PAGES=17,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1951.txt"
}

@TECHREPORT{rfc1952,
AUTHOR="P. Deutsch",
TITLE="{GZIP} file format specification version {4.3}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1952,
PAGES=12,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1952.txt"
}

@TECHREPORT{rfc1953,
AUTHOR="P. Newman and W. L. Edwards and R. Hinden and E. Hoffman and FongChing Liaw
and T. Lyon and G. Minshall",
TITLE="Ipsilon Flow Management Protocol Specification for {IPv4} Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1953,
PAGES=20,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1953.txt"
}

@TECHREPORT{rfc1954,
AUTHOR="P. Newman and W. L. Edwards and R. Hinden and E. Hoffman and FongChing Liaw
and T. Lyon and G. Minshall",
TITLE="Transmission of Flow Labelled {IPv4} on {ATM} Data Links Ipsilon Version
{1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1954,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=1996,
ABSTRACT="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 (IFMP).",
URL="http://www.rfc-editor.org/rfc/rfc1954.txt"
}

@TECHREPORT{rfc1955,
AUTHOR="R. Hinden",
TITLE="New Scheme for Internet Routing and Addressing {(ENCAPS)} for {IPNG}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1955,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="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(at)munnari.oz.au mailing list. 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.",
URL="http://www.rfc-editor.org/rfc/rfc1955.txt"
}

@TECHREPORT{rfc1956,
AUTHOR="D. Engebretson and R. Plzak",
TITLE="Registration in the {MIL} Domain",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1956,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT={This RFC describes the policy for the registration of second
level domains under the {"}.MIL{"} domain.},
URL="http://www.rfc-editor.org/rfc/rfc1956.txt"
}

@TECHREPORT{rfc1957,
AUTHOR="R. T. Nelson",
TITLE="Some Observations on Implementations of the Post Office Protocol {(POP3)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1957,
PAGES=2,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="This memo provides information for the Internet community.
This memo does not specify an Internet standard of any kind.",
URL="http://www.rfc-editor.org/rfc/rfc1957.txt"
}

@TECHREPORT{rfc1958,
EDITOR="B. E. Carpenter",
TITLE="Architectural Principles of the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1958,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1958.txt"
}

@TECHREPORT{rfc1959,
AUTHOR="T. Howes and M. Smith",
TITLE="An {LDAP} {URL} Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1959,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="LDAP is the Lightweight Directory Access Protocol (RFC 1779,
RFC 1777). 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). This RFC is the product of the Access, Searching
and Indexing of Directories Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1959.txt"
}

@TECHREPORT{rfc1960,
AUTHOR="T. Howes",
TITLE="A String Representation of {LDAP} Search Filters",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1960,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="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. This RFC is the product of the Access, Searching and
Indexing of Directories Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1960.txt"
}

@TECHREPORT{rfc1961,
AUTHOR="P. McMahon",
TITLE="{GSS-API} Authentication Method for {SOCKS} Version 5",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1961,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="The protocol specification for SOCKS Version 5 specifies a
generalized framework for the use of arbitrary authentication protocols
in the initial SOCKS connection setup. This document provides the
specification for the SOCKS V5 GSS-API authentication protocol, and
defines a GSS-API-based encapsulation for provision of integrity,
authentication and optional confidentiality. This RFC is the product of
the Authenticated Firewall Traversal Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1961.txt"
}

@TECHREPORT{rfc1962,
AUTHOR="D. Rand",
TITLE="The {PPP} Compression Control Protocol {(CCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1962,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="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. This document defines
a method for negotiating data compression over PPP links. This RFC is
the product of the Point-to-Point Protocol Extensions Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1962.txt"
}

@TECHREPORT{rfc1963,
AUTHOR="K. S. Schneider and S. Venters",
TITLE="{PPP} Serial Data Transport Protocol {(SDTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1963,
PAGES=20,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. 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. This
RFC is the product of the Point-to-Point Protocol Extensions Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1963.txt"
}

@TECHREPORT{rfc1964,
AUTHOR="J. R. Linn",
TITLE="The Kerberos Version 5 {GSS-API} Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1964,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="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). This RFC is the product of the Common Authentication Technology
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1964.txt"
}

@TECHREPORT{rfc1965,
AUTHOR="P. Traina",
TITLE="Autonomous System Confederations for {BGP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1965,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="Border Gateway Protocol is an inter-autonomous system routing
protocol designed for TCP/IP networks. 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. This RFC is the product of
the Inter-Domain Routing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1965.txt"
}

@TECHREPORT{rfc1966,
AUTHOR="T. Bates and R. Chandra",
TITLE="{BGP} Route Reflection An alternative to full mesh {IBGP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1966,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT={The Border Gateway Protocol is 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. This document describes the use and design of a
method known as {"}Route Reflection{"} to alleviate the the need for
{"}full
mesh{"} IBGP. This RFC is the product of the Inter-Domain Routing Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1966.txt"
}

@TECHREPORT{rfc1967,
AUTHOR="K. S. Schneider and R. Friend",
TITLE="{PPP} {LZS-DCP} Compression Protocol {(LZS-DCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1967,
PAGES=18,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides 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. This RFC is the product of the Point-to-Point Protocol
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1967.txt"
}

@TECHREPORT{rfc1968,
AUTHOR="G. Meyer",
TITLE="The {PPP} Encryption Control Protocol {(ECP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1968,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="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. This document defines
a method for negotiating data encryption over PPP links. This RFC is the
product of the Point-to-Point Protocol Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1968.txt"
}

@TECHREPORT{rfc1969,
AUTHOR="K. Sklower and G. Meyer",
TITLE="The {PPP} {DES} Encryption Protocol {(DESE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1969,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links. The
PPP Encryption Control Protocol (ECP) provides a method to negotiate and
utilize encryption protocols over PPP encapsulated links. This document
provides specific details for the use of the DES standard for encrypting
PPP encapsulated packets. This RFC is the product of the Point-to-Point
Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1969.txt"
}

@TECHREPORT{rfc1970,
AUTHOR="T. Narten and E. Nordmark and W. Simpson",
TITLE="Neighbor Discovery for {IP} Version 6 {(IPv6)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1970,
PAGES=82,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. This RFC is the product of the IPNG
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1970.txt"
}

@TECHREPORT{rfc1971,
AUTHOR="S. Thomson and T. Narten",
TITLE="{IPv6} Stateless Address Autoconfiguration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1971,
PAGES=23,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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.
This RFC is the product of the Address Autoconfiguration Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1971.txt"
}

@TECHREPORT{rfc1972,
AUTHOR="M. Crawford",
TITLE="A Method for the Transmission of {IPv6} Packets over Ethernet Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1972,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="This memo specifies the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses on Ethernet
networks. It also specifies the content of the Source/Target Link-layer
Address option used the the Router Solicitation, Router Advertisement,
Neighbor Solicitation, and Neighbor Advertisement messages described in
RFC 1970, when those messages are transmitted on an Ethernet. This RFC
is the product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1972.txt"
}

@TECHREPORT{rfc1973,
AUTHOR="W. Simpson",
TITLE="{PPP} in Frame Relay",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1973,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=1996,
ABSTRACT="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 Frame Relay for framing PPP
encapsulated packets. This RFC is the product of the Point-to-Point
Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1973.txt"
}

@TECHREPORT{rfc1974,
AUTHOR="R. Friend and W. Simpson",
TITLE="{PPP} Stac {LZS} Compression Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1974,
PAGES=20,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides 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. This RFC is the product of the Point-to-Point
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1974.txt"
}

@TECHREPORT{rfc1975,
AUTHOR="D. Schremp and J. P. Black and J. Weiss",
TITLE="{PPP} Magnalink Variable Resource Compression",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1975,
PAGES=6,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
of encapsulating multiple protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method for negotiating
data compression over PPP links. 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. This RFC is the product
of the Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1975.txt"
}

@TECHREPORT{rfc1976,
AUTHOR="K. S. Schneider and S. Venters",
TITLE="{PPP} for Data Compression in Data {Circuit-Terminating} Equipment {(DCE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1976,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. 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 Protocol
provides a standard method for selecting and using a compression
protocol to provide for data compression on a PPP link. 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). This RFC is the
product of the Point-to-Point Protocol Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1976.txt"
}

@TECHREPORT{rfc1977,
AUTHOR="V. Schryver",
TITLE="{PPP} {BSD} Compression Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1977,
PAGES=25,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides 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. This RFC is the product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1977.txt"
}

@TECHREPORT{rfc1978,
AUTHOR="D. Rand",
TITLE="{PPP} Predictor Compression Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1978,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
of encapsulating multiple protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides 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. This RFC is the product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1978.txt"
}

@TECHREPORT{rfc1979,
AUTHOR="J. W. Woods",
TITLE="{PPP} Deflate Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1979,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links. This document
describes the use of the PPP Deflate compression protocol for
compressing PPP encapsulated packets. This RFC is the product of the
Point-to-Point Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1979.txt"
}

@TECHREPORT{rfc1980,
AUTHOR="J. Seidman",
TITLE="A Proposed Extension to {HTML} : {Client-Side} Image Maps",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1980,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc1980.txt"
}

@TECHREPORT{rfc1981,
AUTHOR="J. McCann and S. E. Deering and J. C. Mogul",
TITLE="Path {MTU} Discovery for {IP} version 6",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1981,
PAGES=15,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. This RFC is the product of the IPNG Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1981.txt"
}

@TECHREPORT{rfc1982,
AUTHOR="R. Elz and R. Bush",
TITLE="Serial Number Arithmetic",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1982,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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 RFC 1034 and
RFC 1035. This RFC is the product of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1982.txt"
}

@TECHREPORT{rfc1983,
EDITOR="G. Malkin",
TITLE="Internet Users' Glossary",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1983,
PAGES=62,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. This RFC is the product of the Internet
User Glossary Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1983.txt"
}

@TECHREPORT{rfc1984,
AUTHOR="Anton Riabov and  Iesg",
TITLE="{IAB} and {IESG} Statement on Cryptographic Technology and the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1984,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Internet Architecture Board (IAB) and the Internet
Engineering Steering Group (IESG), the bodies which oversee architecture
and standards for the Internet, are concerned by the need for increased
protection of international commercial transactions on the Internet, and
by the need to offer all Internet users an adequate degree of privacy.
Security mechanisms being developed in the Internet Engineering Task
Force to meet these needs require and depend on the international use of
adequate cryptographic technology. Ready access to such technology is
therefore a key factor in the future growth of the Internet as a motor
for international commerce and communication.",
URL="http://www.rfc-editor.org/rfc/rfc1984.txt"
}

@TECHREPORT{rfc1985,
AUTHOR="J. De Winter",
TITLE="{SMTP} Service Extension for Remote Message Queue Starting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1985,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1985.txt"
}

@TECHREPORT{rfc1986,
AUTHOR="W. Polites and W. Wollman and D. Woo and R. Langan",
TITLE="Experiments with a Simple File Transfer Protocol for Radio Links using
Enhanced Trivial File Transfer Protocol {(ETFTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1986,
PAGES=21,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="This document is a description of the Enhanced Trivial File
Transfer Protocol (ETFTP). This protocol is an experimental
implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998,
as a file transfer application program. It uses the User Datagram
Protocol (UDP), as its transport layer. The two protocols are layered to
create the ETFTP client server application. The ETFTP program is named
after Trivial File Transfer Protocol (TFTP), because the source code
from TFTP is used as the building blocks for the ETFTP program. This
implementation also builds on but differs from the work done by the
National Imagery Transmission Format Standard. This document is
published for discussion and comment on improving the throughput
performance of data transfer utilities over Internet Protocol (IP)
compliant, half duplex, radio networks.",
URL="http://www.rfc-editor.org/rfc/rfc1986.txt"
}

@TECHREPORT{rfc1987,
AUTHOR="P. Newman and W. L. Edwards and R. Hinden and E. Hoffman and FongChing Liaw
and T. Lyon and G. Minshall",
TITLE="Ipsilon's General Switch Management Protocol Specification Version {1.1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1987,
PAGES=44,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1987.txt"
}

@TECHREPORT{rfc1988,
AUTHOR="G. McAnally and D. Gilbert and J. Flick",
TITLE="Conditional Grant of Rights to Specific {Hewlett-Packard} Patents In
Conjunction With the Internet Engineering Task Force's {Internet-Standard}
Network Management Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1988,
PAGES=2,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="This document is NOT a standard. It is an announcement to
interested parties of a conditional grant by the Hewlett-Packard Company
(HP) of certain rights to use autotopology network management technology
covered by specific HP patents in conjunction with the Internet
Engineering Task Force's (IETF's) Internet-standard network management
framework. This grant is made to help facilitate inclusion of certain
patented search address technology covering network device mapping in
IETF standards-track Management Information Base (MIB) modules. HP is
offering this search address technology to the IETF as a technique for
mapping network devices. It should be noted that the confirmatory
license mentioned is optional, since the grant of rights is automatic.",
URL="http://www.rfc-editor.org/rfc/rfc1988.txt"
}

@TECHREPORT{rfc1989,
AUTHOR="W. Simpson",
TITLE="{PPP} Link Quality Monitoring",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1989,
PAGES=16,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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 a Quality Protocol for continuous monitoring of the
viability of the link. This document defines a protocol for generating
Link-Quality-Reports. This RFC is the product of the Point-to-Point
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1989.txt"
}

@TECHREPORT{rfc1990,
AUTHOR="K. Sklower and B. Lloyd and G. McGregor and D. Carr and T. Coradetti",
TITLE="The {PPP} Multilink Protocol {(MP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1990,
PAGES=24,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. The differences
between the current PPP Multilink specification (RFC 1717) 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. This RFC is the product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1990.txt"
}

@TECHREPORT{rfc1991,
AUTHOR="D. Atkins and W. Stallings and P. Zimmermann",
TITLE="{PGP} Message Exchange Formats",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1991,
PAGES=21,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT={PGP (Pretty Good Privacy) uses a combination of public-key and
conventional encryption to provide security services for electronic mail
messages and data files. These services include confidentiality and
digital signature. PGP is widely used throughout the global computer
community. This document describes the format of {"}PGP files{"}, i.e.,
messages that have been encrypted and/or signed with PGP.},
URL="http://www.rfc-editor.org/rfc/rfc1991.txt"
}

@TECHREPORT{rfc1992,
AUTHOR="I. Castineyra and N. Chiappa and M. Steenstrup",
TITLE="The Nimrod Routing Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1992,
PAGES=27,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc1992.txt"
}

@TECHREPORT{rfc1993,
AUTHOR="A. Barbir and D. Carr and W. Simpson",
TITLE="{PPP} Gandalf {FZA} Compression Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1993,
PAGES=6,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links. This document
describes the use of the Gandalf FZA data compression algorithm for
compressing PPP encapsulated packets. This RFC is the product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1993.txt"
}

@TECHREPORT{rfc1994,
AUTHOR="W. Simpson",
TITLE="{PPP} Challenge Handshake Authentication Protocol {(CHAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1994,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. 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. This RFC is the product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1994.txt"
}

@TECHREPORT{rfc1995,
AUTHOR="M. Ohta",
TITLE="Incremental Zone Transfer in {DNS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1995,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="This document proposes extensions to the DNS protocols to
provide an incremental zone transfer (IXFR) mechanism. This RFC is a
product of the DNS IXFR, Notification, and Dynamic Update Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1995.txt"
}

@TECHREPORT{rfc1996,
AUTHOR="P. Vixie",
TITLE="A Mechanism for Prompt Notification of Zone Changes {(DNS} {NOTIFY)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1996,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="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. This RFC is a product of the DNS IXFR, Notification, and Dynamic
Update Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1996.txt"
}

@TECHREPORT{rfc1997,
AUTHOR="R. Chandra and P. Traina and T. Li",
TITLE="{BGP} Communities Attribute",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1997,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT="The Border Gateway Protocol is 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. This RFC is the product of the
Inter-Domain Routing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc1997.txt"
}

@TECHREPORT{rfc1998,
AUTHOR="E. H. Chen and T. Bates",
TITLE="An Application of the {BGP} Community Attribute in Multi-home Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1998,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1996,
ABSTRACT={This document presents an application of the BGP community
attribute in 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. This RFC is the product of
the Inter-Domain Routing Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc1998.txt"
}

@TECHREPORT{rfc2002,
EDITOR="C. E. Perkins",
TITLE="{IP} Mobility Support",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2002,
PAGES=79,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This document specifies protocol enhancements that allow
transparent routing of IP datagrams to mobile nodes in the Internet.
Each mobile node is always identified by its home address, regardless of
its current point of attachment to the Internet. While situated away
from its home, a mobile node is also associated with a care-of address,
which provides information about its current point of attachment to the
Internet. The protocol provides for registering the care-of address with
a home agent. The home agent sends datagrams destined for the mobile
node through a tunnel to the care-of address. After arriving at the end
of the tunnel, each datagram is then delivered to the mobile node. This
RFC is a product of the IP Routing for Wireless/ Mobile Hosts Working
Group.",
URL="http://www.rfc-editor.org/rfc/rfc2002.txt"
}

@TECHREPORT{rfc2003,
AUTHOR="C. E. Perkins",
TITLE="{IP} Encapsulation within {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2003,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a product of the IP Routing for Wireless/
Mobile Hosts Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2003.txt"
}

@TECHREPORT{rfc2004,
AUTHOR="C. E. Perkins",
TITLE="Minimal Encapsulation within {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2004,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT={This document specifies a method by which an IP datagram may
be encapsulated (carried as payload) within an IP datagram, with less
overhead than {"}conventional{"} 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. This RFC is a
product of the IP Routing for Wireless/Mobile Hosts Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2004.txt"
}

@TECHREPORT{rfc2005,
AUTHOR="J. Solomon",
TITLE="Applicability Statement for {IP} Mobility Support",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2005,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is the product of the IP Routing for
Wireless/Mobile Hosts Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2005.txt"
}

@TECHREPORT{rfc2006,
AUTHOR="D. Cong and M. Hamlen and C. E. Perkins",
TITLE="The Definitions of Managed Objects for {IP} Mobility Support using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2006,
PAGES=52,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC
is a product of the IP Routing for Wireless/Mobile Hosts Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2006.txt"
}

@TECHREPORT{rfc2007,
AUTHOR="J. Foster and M. Isaacs and M. Prior",
TITLE="Catalogue of Network Training Materials",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2007,
PAGES=55,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is produced
as a collaborative effort by the Joint IETF/TERENA(RARE) Network
Training Materials - Working Group (TRAINMAT).",
URL="http://www.rfc-editor.org/rfc/rfc2007.txt"
}

@TECHREPORT{rfc2008,
AUTHOR="Y. Rekhter and T. Li",
TITLE="Implications of Various Address Allocation Policies for Internet Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2008,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="The purpose of this document is to articulate certain relevant
fundamental technical issues that must be considered in formulating
unicast address allocation and management policies for the Public
Internet, and to provide recommendations with respect to these policies.
This RFC is a product of the CIDR Deployment Working Group of the IETF.
IESG Note: 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.",
URL="http://www.rfc-editor.org/rfc/rfc2008.txt"
}

@TECHREPORT{rfc2009,
AUTHOR="T. Imielinski and J. C. Navas",
TITLE="{GPS-Based} Addressing and Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2009,
PAGES=27,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="In this document we propose a family of protocols and
addressing methods to integrate GPS into the Internet Protocol to enable
the creation of location dependent services.",
URL="http://www.rfc-editor.org/rfc/rfc2009.txt"
}

@TECHREPORT{rfc2010,
AUTHOR="B. Manning and P. Vixie",
TITLE="Operational Criteria for Root Name Servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2010,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This document specifies the operational requirements of root
name servers, including host hardware capacities, name server software
revisions, network connectivity, and physical environment.",
URL="http://www.rfc-editor.org/rfc/rfc2010.txt"
}

@TECHREPORT{rfc2011,
EDITOR="K. McCloghrie",
TITLE="{SNMPv2} Management Information Base for the Internet Protocol using
{SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2011,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="This document is the MIB module which defines managed objects
for managing implementations of the Internet Protocol (IP) and its
associated Internet Control Message Protocol (ICMP). This RFC is the
product of the SNMP Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2011.txt"
}

@TECHREPORT{rfc2012,
EDITOR="K. McCloghrie",
TITLE="{SNMPv2} Management Information Base for the Transmission Control Protocol
using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2012,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="This document is the MIB module which defines managed objects
for managing implementations of the Transmission Control Protocol (TCP).
This RFC is the product of the SNMP Version 2 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2012.txt"
}

@TECHREPORT{rfc2013,
EDITOR="K. McCloghrie",
TITLE="{SNMPv2} Management Information Base for the User Datagram Protocol using
{SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2013,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="This document is the MIB module which defines managed objects
for managing implementations of the User Datagram Protocol (UDP). This
RFC is a product of the SNMP Version 2 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2013.txt"
}

@TECHREPORT{rfc2014,
AUTHOR="A. Weinrib and J. B. Postel",
TITLE="{IRTF} Research Group Guidelines and Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2014,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This document is a product of the Internet Architecture Board
(IAB).",
URL="http://www.rfc-editor.org/rfc/rfc2014.txt"
}

@TECHREPORT{rfc2015,
AUTHOR="M. Elkins",
TITLE="{MIME} Security with Pretty Good Privacy {(PGP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2015,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2015.txt"
}

@TECHREPORT{rfc2016,
AUTHOR="L. Daigle and P. Deutsch and B. Heelan and C. Alpaugh and M. Maclachlan",
TITLE="Uniform Resource Agents {(URAs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2016,
PAGES=21,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2016.txt"
}

@TECHREPORT{rfc2017,
AUTHOR="N. Freed and K. Moore and A. Cargille",
TITLE="Definition of the {URL} {MIME} {External-Body} {Access-Type}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2017,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo defines a new access-type for message/external-body
MIME parts for Uniform Resource Locators (URLs). URLs provide schemes to
access external objects via a growing number of protocols, including
HTTP, Gopher, and TELNET. An initial set of URL schemes are defined in
RFC 1738. This RFC is the product of the Mail Extensions Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2017.txt"
}

@TECHREPORT{rfc2018,
AUTHOR="M. Mathis and J. Mahdavi and S. Floyd and A. Romanow",
TITLE="{TCP} Selective Acknowledgement Options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2018,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo proposes an implementation of SACK and discusses its
performance and related issues. This RFC is a product of the TCP Large
Windows Working Group.",
URL="http://www.rfc-editor.org/rfc/rfc2018.txt"
}

@TECHREPORT{rfc2019,
AUTHOR="M. Crawford",
TITLE="Transmission of {IPv6} Packets Over {FDDI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2019,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo specifies the MTU and frame format for transmission
of IPv6 packets on FDDI networks, including a method for MTU
determination in the presence of 802.1d bridges to other media. It also
specifies the method of forming IPv6 link-local addresses on FDDI
networks and the content of the Source/Target Link-layer Address option
used the the Router Solicitation, Router Advertisement, Neighbor
Solicitation, and Neighbor Advertisement messages described in RFC 1970,
when those messages are transmitted on an FDDI network. This RFC is a
product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2019.txt"
}

@TECHREPORT{rfc2020,
AUTHOR="J. Flick",
TITLE="{IEEE} {802.12} Interface {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2020,
PAGES=31,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing network
interfaces based on IEEE 802.12. This RFC is a product of the
100VG-AnyLAN MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2020.txt"
}

@TECHREPORT{rfc2022,
AUTHOR="G. Armitage",
TITLE="Support for Multicast over {UNI} {3.0/3.1} based {ATM} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2022,
PAGES=82,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="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. This RFC is a product of
the IP/ATM working group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2022.txt"
}

@TECHREPORT{rfc2023,
AUTHOR="D. Haskin and E. B. Allen",
TITLE="{IP} Version 6 over {PPP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2023,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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.
This RFC is a product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2023.txt"
}

@TECHREPORT{rfc2024,
EDITOR="D. X. Chen and P. Gayek and S. Nix",
TITLE="Definitions of Managed Objects for Data Link Switching using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2024,
PAGES=90,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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). This memo specifies a MIB module
in a manner that is both compliant to the SNMPv2 SMI, and semantically
identical to the SNMPv1 definitions. This RFC is a product of Data Link
Switching MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2024.txt"
}

@TECHREPORT{rfc2025,
AUTHOR="C. J. Adams",
TITLE="The Simple {Public-Key} {GSS-API} Mechanism {(SPKM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2025,
PAGES=45,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a product
is of the Common Authentication Technology Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2025.txt"
}

@TECHREPORT{rfc2026,
AUTHOR="S. Bradner",
TITLE="The Internet Standards Process {--} Revision 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2026,
PAGES=36,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a
product of the Process for the Organization of Internet Standards '95
(Poised95) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2026.txt"
}

@TECHREPORT{rfc2027,
AUTHOR="J. Galvin",
TITLE="{IAB} and {IESG} Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2027,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a
product of the Process for Organization of Internet Standards '95
(Poised95) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2027.txt"
}

@TECHREPORT{rfc2028,
AUTHOR="R. B. Hovey and S. Bradner",
TITLE="The Organizations Involved in the {IETF} Standards Process",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2028,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a product of the Process for Organization of
Internet Standards '95 (Poised95) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2028.txt"
}

@TECHREPORT{rfc2029,
AUTHOR="M. Speer and D. Hoffman",
TITLE="{RTP} Payload Format of Sun's {CellB} Video Encoding",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2029,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This
RFC is a product of the Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2029.txt"
}

@TECHREPORT{rfc2030,
AUTHOR="D. L. Mills",
TITLE="Simple Network Time Protocol {(SNTP)} Version 4 for {IPv4,} {IPv6} and
{OSI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2030,
PAGES=18,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2030.txt"
}

@TECHREPORT{rfc2031,
AUTHOR="E. Huizer",
TITLE="{IETF-ISOC} relationship",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2031,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a product of the Process for
Organization of Internet Standards '95 (Poised95) Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2031.txt"
}

@TECHREPORT{rfc2032,
AUTHOR="T. Turletti and C. Huitema",
TITLE="{RTP} Payload Format for {H.261} Video Streams",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2032,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo describes a scheme to packetize an H.261 video
stream for transport using the Real-time Transport Protocol, RTP, with
any of the underlying protocols that carry RTP. This RFC is a product of
the Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2032.txt"
}

@TECHREPORT{rfc2033,
AUTHOR="J. Myers",
TITLE="Local Mail Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2033,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This document describes the LMTP (Local Mail Transfer
Protocol) protocol for transporting mail into such systems.",
URL="http://www.rfc-editor.org/rfc/rfc2033.txt"
}

@TECHREPORT{rfc2034,
AUTHOR="N. Freed",
TITLE="{SMTP} Service Extension for Returning Enhanced Error Codes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2034,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo defines an extension to the SMTP service (RFC-821,
RFC-1869) whereby an SMTP server augments its responses with the
enhanced mail system status codes defined in RFC 1893. These codes can
then be used to provide more informative explanations of error
conditions, especially in the context of the delivery status
notifications format defined in RFC 1894. This RFC is a product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2034.txt"
}

@TECHREPORT{rfc2035,
AUTHOR="L. Berc and W. Fenner and R. Frederick and S. McCanne",
TITLE="{RTP} Payload Format for {JPEG-compressed} Video",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2035,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a
product of the Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2035.txt"
}

@TECHREPORT{rfc2036,
AUTHOR="G. Huston",
TITLE="Observations on the use of Components of the Class A Address Space within
the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2036,
PAGES=9,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a product of the CIDR Deployment
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2036.txt"
}

@TECHREPORT{rfc2037,
AUTHOR="K. McCloghrie and A. Bierman",
TITLE="Entity {MIB} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2037,
PAGES=35,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
multiple logical and physical entities managed by a single SNMP agent.
This RFC is a product of the Entity MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2037.txt"
}

@TECHREPORT{rfc2038,
AUTHOR="D. Hoffman and G. Fernando and V. Goyal",
TITLE="{RTP} Payload Format for {MPEG1/MPEG2} Video",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2038,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo describes a packetization scheme for MPEG video and
audio streams. The scheme proposed can be used to transport such a video
or audio flow over the transport protocols supported by RTP. Two
approaches are described. The first is designed to support maximum
interoperability with MPEG System environments. The second is designed
to provide maximum compatibility with other RTP-encapsulated media
streams and future conference control work of the IETF. This RFC is a
product of the Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2038.txt"
}

@TECHREPORT{rfc2039,
AUTHOR="C. Kalbfleisch",
TITLE="Applicability of Standards Track {MIBs} to Management of World Wide Web
Servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2039,
PAGES=14,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="Requirements for management of a World Wide Web (WWW) server
are presented. The applicable existing standards track MIBs are then
examined. Finally, an analysis of the additional groups of MIB
attributes that are needed to meet the requirements is presented.",
URL="http://www.rfc-editor.org/rfc/rfc2039.txt"
}

@TECHREPORT{rfc2040,
AUTHOR="R. Baldwin and R. Rivest",
TITLE="The {RC5,} {RC5-CBC,} {RC5-CBC-Pad,} and {RC5-CTS} Algorithms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2040,
PAGES=29,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This document defines four ciphers with enough detail to
ensure interoperability between different implementations.",
URL="http://www.rfc-editor.org/rfc/rfc2040.txt"
}

@TECHREPORT{rfc2041,
AUTHOR="B. Noble and G. T. Nguyen and M. Satyanarayanan and Randy H. Katz",
TITLE="Mobile Network Tracing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2041,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2041.txt"
}

@TECHREPORT{rfc2043,
AUTHOR="A. Fuqua",
TITLE="The {PPP} {SNA} Control Protocol {(SNACP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2043,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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. This RFC is a product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2043.txt"
}

@TECHREPORT{rfc2044,
AUTHOR="F. Yergeau",
TITLE="{UTF-8,} a transformation format of Unicode and {ISO} 10646",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2044,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2044.txt"
}

@TECHREPORT{rfc2045,
AUTHOR="N. Freed and N. Borenstein",
TITLE="Multipurpose Internet Mail Extensions {(MIME)} Part One: Format of Internet
Message Bodies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2045,
PAGES=31,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="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
textual message bodies in character sets other than US-ASCII, an
extensible set of different formats for non-textual message bodies,
multi-part message bodies, and textual header information in character
sets other than US-ASCII. This initial document specifies the various
headers used to describe the structure of MIME messages.",
URL="http://www.rfc-editor.org/rfc/rfc2045.txt"
}

@TECHREPORT{rfc2046,
AUTHOR="N. Freed and N. Borenstein",
TITLE="Multipurpose Internet Mail Extensions {(MIME)} Part Two: Media Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2046,
PAGES=44,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="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
textual message bodies in character sets other than US-ASCII, an
extensible set of different formats for non-textual message bodies,
multi-part message bodies, and textual header information in character
sets other than US-ASCII. This second document defines the general
structure of the MIME media typing system and defines an initial set of
media types.",
URL="http://www.rfc-editor.org/rfc/rfc2046.txt"
}

@TECHREPORT{rfc2047,
AUTHOR="K. Moore",
TITLE="{MIME} (Multipurpose Internet Mail Extensions) Part Three: Message Header
Extensions for {Non-ASCII} Text",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2047,
PAGES=15,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="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
textual message bodies in character sets other than US-ASCII, an
extensible set of different formats for non-textual message bodies,
multi-part message bodies, and (4) textual header information in
character sets other than US-ASCII. This third document in the series
describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields.",
URL="http://www.rfc-editor.org/rfc/rfc2047.txt"
}

@TECHREPORT{rfc2048,
AUTHOR="N. Freed and J. Klensin and J. B. Postel",
TITLE="Multipurpose Internet Mail Extensions {(MIME)} Part Four: Registration
Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2048,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="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
textual message bodies in character sets other than US-ASCII, an
extensible set of different formats for non-textual message bodies,
multi-part message bodies, and textual header information in character
sets other than US-ASCII. This memo specifies various IANA registration
procedures for the following MIME facilities: media types, external body
access types, content-transfer-encodings.",
URL="http://www.rfc-editor.org/rfc/rfc2048.txt"
}

@TECHREPORT{rfc2049,
AUTHOR="N. Freed and N. Borenstein",
TITLE="Multipurpose Internet Mail Extensions {(MIME)} Part Five: Conformance
Criteria and Examples",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2049,
PAGES=24,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="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
textual message bodies in character sets other than US-ASCII, an
extensible set of different formats for non-textual message bodies,
multi-part message bodies, and textual header information in character
sets other than US-ASCII. This fifth document describes MIME conformance
criteria as well as providing some illustrative examples of MIME message
formats, acknowledgements, and the bibliography.",
URL="http://www.rfc-editor.org/rfc/rfc2049.txt"
}

@TECHREPORT{rfc2050,
AUTHOR="K. Hubbard and M. Kosters and D. Conrad and D. Karrenberg and J. B. Postel",
TITLE="Internet Registry {IP} Allocation Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2050,
PAGES=13,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="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. This RFC is
a product of the CIDR Deployment Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2050.txt"
}

@TECHREPORT{rfc2051,
AUTHOR="M. Allen and B. Clouston and Z. Kielczewski and W. Kwan and B. W. Moore",
TITLE="Definitions of Managed Objects for {APPC} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2051,
PAGES=124,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing the
configuration, monitoring and controlling of network devices with APPC
(Advanced Program-to-Program Communications) capabilities. This memo
identifies managed objects for the SNA LU6.2 protocols. This RFC is a
product of the SNA NAU MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2051.txt"
}

@TECHREPORT{rfc2052,
AUTHOR="A. Gulbrandsen and P. Vixie",
TITLE="A {DNS} {RR} for specifying the location of services {(DNS} {SRV)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2052,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2052.txt"
}

@TECHREPORT{rfc2053,
AUTHOR="E. Der-Danieliantz",
TITLE="The {AM} (Armenia) Domain",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2053,
PAGES=3,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="The AM Domain is an official Internet top-level domain of
Armenia.",
URL="http://www.rfc-editor.org/rfc/rfc2053.txt"
}

@TECHREPORT{rfc2054,
AUTHOR="B. Callaghan",
TITLE="{WebNFS} Client Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2054,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2054.txt"
}

@TECHREPORT{rfc2055,
AUTHOR="B. Callaghan",
TITLE="{WebNFS} Server Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2055,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=1996,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2055.txt"
}

@TECHREPORT{rfc2056,
AUTHOR="R. Denenberg and J. Kunze and D. Lynch",
TITLE="Uniform Resource Locators for {Z39.50}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2056,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="Z39.50 is an information retrieval protocol that does not fit
neatly into a retrieval model designed primarily around the stateless
fetch of data. Instead, it models a general user inquiry as a
session-oriented, multi-step task, any step of which may be suspended
temporarily while the server requests additional parameters from the
client before continuing. This RFC is a product of the Uniform Resource
Identifiers Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2056.txt"
}

@TECHREPORT{rfc2057,
AUTHOR="S. Bradner",
TITLE="Source Directed Access Control on the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2057,
PAGES=20,
DAYS=15,
MONTH=nov,
YEAR=1996,
ABSTRACT="This memo was developed from a deposition that Scott Bradner
submitted as part of a challenge to the Communications Decency Act of
1996, part of the Telecommunications Reform Act of 1996. This document
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.",
URL="http://www.rfc-editor.org/rfc/rfc2057.txt"
}

@TECHREPORT{rfc2060,
AUTHOR="M. R. Crispin",
TITLE="Internet Message Access Protocol - Version 4rev1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2060,
PAGES=82,
DAYS=15,
MONTH=dec,
YEAR=1996,
ABSTRACT="The Internet Message Access Protocol, Version 4rev1
(IMAP4rev1) allows a client to access and manipulate electronic mail
messages on a server. 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 RFC
2062. Other compatibility issues with IMAP2bis, the most common variant
of the earlier protocol, are discussed in RFC 2061. A full discussion of
compatibility issues with rare (and presumed extinct) variants of IMAP2
is in RFC 1732; this document is primarily of historical interest",
URL="http://www.rfc-editor.org/rfc/rfc2060.txt"
}

@TECHREPORT{rfc2061,
AUTHOR="M. R. Crispin",
TITLE="{IMAP4} Compatibility with {IMAP2bis}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2061,
PAGES=3,
DAYS=15,
MONTH=dec,
YEAR=1996,
ABSTRACT="The Internet Message Access Protocol (IMAP) has been through
several revisions and variants in its 10-year history. Many of these are
either extinct or extremely rare; in particular, several undocumented
variants and the variants described in RFC 1064, RFC 1176, and RFC 1203
fall into this category. One variant, IMAP2bis, is at the time of this
writing very common and has been widely distributed with the Pine
mailer. Unfortunately, there is no definite document describing
IMAP2bis. This document is intended to be read along with RFC 1176 and
the most recent IMAP4 specification (RFC 2060) to assist implementors in
creating an IMAP4 implementation to interoperate with implementations
that conform to earlier specifications. Nothing in this document is
required by the IMAP4 specification; implementors must decide for
themselves whether they want their implementation to fail if it
encounters old software. At the time of this writing, IMAP4 has been
updated from the version described in RFC 1730. An implementor who
wishes to interoperate with both RFC 1730 and RFC 2060 should refer to
both documents.",
URL="http://www.rfc-editor.org/rfc/rfc2061.txt"
}

@TECHREPORT{rfc2062,
AUTHOR="M. R. Crispin",
TITLE="Internet Message Access Protocol - Obsolete Syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2062,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1996,
ABSTRACT="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. This document repeats information from earlier
documents, most notably RFC 1176 and RFC 1730.",
URL="http://www.rfc-editor.org/rfc/rfc2062.txt"
}

@TECHREPORT{rfc1299,
AUTHOR="M. Kennedy",
TITLE="Summary of {1200-1299}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1299,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1200 through RFCs 1299. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1299.txt"
}

@TECHREPORT{rfc1399,
AUTHOR="J. Elliott",
TITLE="Summary of {1300-1399}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1399,
PAGES=22,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1300 through RFCs 1399. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1399.txt"
}

@TECHREPORT{rfc1499,
AUTHOR="J. Elliott",
TITLE="Summary of {1400-1499}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1499,
PAGES=21,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1400 through RFCs 1499. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1499.txt"
}

@TECHREPORT{rfc1599,
AUTHOR="M. Kennedy",
TITLE="Summary of {1500-1599}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1599,
PAGES=22,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1500 through RFCs 1599. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1599.txt"
}

@TECHREPORT{rfc1699,
AUTHOR="J. Elliott",
TITLE="Summary of {1600-1699}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1699,
PAGES=21,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1600 through RFCs 1699. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1699.txt"
}

@TECHREPORT{rfc1799,
AUTHOR="M. Kennedy",
TITLE="Request for Comments Summary {RFC} Numbers {1700-1799}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1799,
PAGES=21,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1700 through RFCs 1799. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1799.txt"
}

@TECHREPORT{rfc1899,
AUTHOR="J. Elliott",
TITLE="Request for Comments Summary {RFC} Numbers {1800-1899}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1899,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1800 through RFCs 1899. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1899.txt"
}

@TECHREPORT{rfc1999,
AUTHOR="J. Elliott",
TITLE="Request for Comments Summary {RFC} Numbers {1900-1999}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=1999,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
1900 through RFCs 1999. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc1999.txt"
}

@TECHREPORT{rfc2000,
AUTHOR="Editor J. Postel",
EDITOR="J. B. Postel",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2000,
PAGES=56,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="This memo describes the state of standardization of protocols
used in the Internet as determined by the Internet Architecture Board
(IAB).",
URL="http://www.rfc-editor.org/rfc/rfc2000.txt"
}

@TECHREPORT{rfc2001,
AUTHOR="W. Richard Stevens",
TITLE="{TCP} Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery
Algorithms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2001,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.
The purpose of this document is to document these four algorithms for
the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc2001.txt"
}

@TECHREPORT{rfc2021,
AUTHOR="S. Waldbusser",
TITLE="Remote Network Monitoring Management Information Base Version 2 using
{SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2021,
PAGES=130,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring devices. This document is a product of the Remote Network
Monitoring Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2021.txt"
}

@TECHREPORT{rfc2042,
AUTHOR="B. Manning",
TITLE="Registering New {BGP} Attribute Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2042,
PAGES=3,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This document describes the process for creating new BGP
attribute type codes.",
URL="http://www.rfc-editor.org/rfc/rfc2042.txt"
}

@TECHREPORT{rfc2058,
AUTHOR="C. Rigney and A. Rubens and W. Simpson and S. Willens",
TITLE="Remote Authentication Dial In User Service {(RADIUS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2058,
PAGES=64,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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. This document is the product of the Remote
Authentication Dial-In-User Service Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2058.txt"
}

@TECHREPORT{rfc2059,
AUTHOR="C. Rigney",
TITLE="{RADIUS} Accounting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2059,
PAGES=25,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This document describes a protocol for carrying accounting
information between a Network Access Server and a shared Accounting
Server. This document is a product of the Remote Authentication Dial-In
User Service Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2059.txt"
}

@TECHREPORT{rfc2063,
AUTHOR="Nevil Brownlee and C. B. Mills and G. Ruth",
TITLE="Traffic Flow Measurement: Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2063,
PAGES=37,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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. This document is a product of the Realtime
Traffic Flow Measurement Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2063.txt"
}

@TECHREPORT{rfc2064,
AUTHOR="Nevil Brownlee",
TITLE="Traffic Flow Measurement: Meter {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2064,
PAGES=38,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, this memo defines managed objects used for
obtaining traffic flow information from network traffic meters. This
document is a product of the Realtime Traffic Flow Measurement Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2064.txt"
}

@TECHREPORT{rfc2065,
AUTHOR="D. Eastlake 3rd and C. Kaufman",
TITLE="Domain Name System Security Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2065,
PAGES=41,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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. This document is a product of the DNS Security Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2065.txt"
}

@TECHREPORT{rfc2066,
AUTHOR="R. Gellens",
TITLE="{TELNET} {CHARSET} Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2066,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2066.txt"
}

@TECHREPORT{rfc2067,
AUTHOR="J. Renwick",
TITLE="{IP} over {HIPPI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2067,
PAGES=30,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This document describes the use of HIPPI switches as IP local
area networks. This memo is a revision of RFC 1374, 'IP and ARP on
HIPPI', and is intended to replace it in the Standards Track.",
URL="http://www.rfc-editor.org/rfc/rfc2067.txt"
}

@TECHREPORT{rfc2068,
AUTHOR="R. Fielding and J. Gettys and J. C. Mogul and H. Frystyk and T. Berners-Lee",
TITLE="Hypertext Transfer Protocol {--} {HTTP/1.1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2068,
PAGES=162,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT={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{"}. This document is a product of the HyperText Transfer
Protocol Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2068.txt"
}

@TECHREPORT{rfc2069,
AUTHOR="J. Franks and P. Hallam-Baker and J. Hostetler and P. J. Leach and A.
Luotonen and E. Sink and L. Stewart",
TITLE="An Extension to {HTTP} : Digest Access Authentication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2069,
PAGES=18,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT={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{"}. This document is
a product of the HyperText Transfer Protocol Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2069.txt"
}

@TECHREPORT{rfc2070,
AUTHOR="F. Yergeau and G. Nicol and G. C. Adams and M. Duerst",
TITLE="Internationalization of the Hypertext Markup Language",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2070,
PAGES=43,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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. This document
is the product of the HyperText Markup Language Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2070.txt"
}

@TECHREPORT{rfc2071,
AUTHOR="P. Ferguson and H. Berkowitz",
TITLE="Network Renumbering Overview: Why would I want it and what is it anyway?",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2071,
PAGES=14,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2071.txt"
}

@TECHREPORT{rfc2072,
AUTHOR="H. Berkowitz",
TITLE="Router Renumbering Guide",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2072,
PAGES=48,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2072.txt"
}

@TECHREPORT{rfc2073,
AUTHOR="Y. Rekhter and P. Lothberg and R. Hinden and S. E. Deering and J. B. Postel",
TITLE="An {IPv6} {Provider-Based} Unicast Address Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2073,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT={This document defines an IPv6 provider-based unicast address
format for use in the Internet. The address format defined in this
document is consistent with the {"}IPv6 Addressing Architecture{"} and the
{"}An Architecture for IPv6 Unicast Address Allocation{"}, and is intended
to facilitate scalable Internet routing. This document is a product of
the IPNG Working Group.},
URL="http://www.rfc-editor.org/rfc/rfc2073.txt"
}

@TECHREPORT{rfc2074,
AUTHOR="A. Bierman and R. Iddon",
TITLE="Remote Network Monitoring {MIB} Protocol Identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2074,
PAGES=43,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in the
Internet community. In particular, it describes the algorithms required
to identify different protocol encapsulations managed with the Remote
Network Monitoring MIB Version 2 (RMON2). Although related to the
original Remote Network Monitoring MIB (RFC1757), this document refers
only to objects found in the RMON-2 MIB. This document is the product of
the Remote Network Monitoring Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2074.txt"
}

@TECHREPORT{rfc2075,
AUTHOR="C. Partridge",
TITLE="{IP} Echo Host Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2075,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2075.txt"
}

@TECHREPORT{rfc2076,
AUTHOR="J. Palme",
TITLE="Common Internet Message Headers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2076,
PAGES=27,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="This memo contains a table of commonly occurring headers in
headings of e-mail messages. This document is a product of the Mail
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2076.txt"
}

@TECHREPORT{rfc2077,
AUTHOR="S. Nelson and C. Parks and Soumitra Nandy",
TITLE="The Model Primary Content Type for Multipurpose Internet Mail Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2077,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT={The purpose of this memo is to propose an update to Internet
RFC 2045 to include a new primary content-type to be known as {"}model{"}.
RFC 2045 describes mechanisms for specifying and describing the format
of Internet Message Bodies via content-type/subtype pairs. We believe
that {"}model{"} defines a fundamental type of content with unique
presentational, hardware, and processing aspects. Various subtypes of
this primary type are immediately anticipated but will be covered under
separate documents.},
URL="http://www.rfc-editor.org/rfc/rfc2077.txt"
}

@TECHREPORT{rfc2078,
AUTHOR="J. R. Linn",
TITLE="Generic Security Service Application Program Interface, Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2078,
PAGES=85,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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. This document is a product of the
Common Authentication Technology Working Group.",
URL="http://www.rfc-editor.org/rfc/rfc2078.txt"
}

@TECHREPORT{rfc2079,
AUTHOR="M. Smith",
TITLE="Definition of an {X.500} Attribute Type and an Object Class to Hold Uniform
Resource Identifiers {(URIs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2079,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2079.txt"
}

@TECHREPORT{rfc2080,
AUTHOR="G. Malkin and R. Minnear",
TITLE="{RIPng} for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2080,
PAGES=19,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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. This document is a product of the Routing
Information Protocol Working Group.",
URL="http://www.rfc-editor.org/rfc/rfc2080.txt"
}

@TECHREPORT{rfc2081,
AUTHOR="G. Malkin",
TITLE="{RIPng} Protocol Applicability Statement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2081,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2081.txt"
}

@TECHREPORT{rfc2082,
AUTHOR="F. Baker and R. Atkinson",
TITLE="{RIP-2} {MD5} Authentication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2082,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="We propose that RIP-2 use an authentication algorithm, as was
originally proposed for SNMP Version 2, augmented by a sequence number.
This is a product of the RIP Working Group.",
URL="http://www.rfc-editor.org/rfc/rfc2082.txt"
}

@TECHREPORT{rfc2083,
AUTHOR="T. Boutell",
TITLE="{PNG} (Portable Network Graphics) Specification Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2083,
PAGES=102,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="This document describes PNG (Portable Network Graphics), an
extensible file format for the lossless, portable, well-compressed
storage of raster images. This specification defines the Internet Media
Type image/png.",
URL="http://www.rfc-editor.org/rfc/rfc2083.txt"
}

@TECHREPORT{rfc2084,
AUTHOR="Martin Bossert and S. C. Cooper and W. Drummond",
TITLE="Considerations for Web Transaction Security",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2084,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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. This document is a product of the Web
Transaction Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2084.txt"
}

@TECHREPORT{rfc2085,
AUTHOR="Michael  Oehler and R. Glenn",
TITLE="{HMAC-MD5} {IP} Authentication with Replay Prevention",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2085,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="This document describes a keyed-MD5 transform to be used in
conjunction with the IP Authentication Header (RFC-1826). This document
is the product of the IP Security Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2085.txt"
}

@TECHREPORT{rfc2086,
AUTHOR="J. Myers",
TITLE="{IMAP4} {ACL} extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2086,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="The ACL extension of the Internet Message Access Protocol
(IMAP4) permits access control lists to be manipulated through the IMAP
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2086.txt"
}

@TECHREPORT{rfc2087,
AUTHOR="J. Myers",
TITLE="{IMAP4} {QUOTA} extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2087,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="The QUOTA extension of the Internet Message Access Protocol
(IMAP4) permits administrative limits on resource usage (quotas) to be
manipulated through the IMAP protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2087.txt"
}

@TECHREPORT{rfc2088,
AUTHOR="J. Myers",
TITLE="{IMAP4} non-synchronizing literals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2088,
PAGES=2,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT={The Internet Message Access Protocol (IMAP4) contains 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.},
URL="http://www.rfc-editor.org/rfc/rfc2088.txt"
}

@TECHREPORT{rfc2089,
AUTHOR="B. Wijnen and D. Levi",
TITLE="{V2ToV1} Mapping {SNMPv2} onto {SNMPv1} within a bi-lingual {SNMP} agent",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2089,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2089.txt"
}

@TECHREPORT{rfc2090,
AUTHOR="A. Emberson",
TITLE="{TFTP} Multicast Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2090,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2090.txt"
}

@TECHREPORT{rfc2091,
AUTHOR="G. Meyer and S. Sherry",
TITLE="Triggered Extensions to {RIP} to Support Demand Circuits",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2091,
PAGES=22,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.
This document is the product of the Routing Information Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2091.txt"
}

@TECHREPORT{rfc2092,
AUTHOR="S. Sherry and G. Meyer",
TITLE="Protocol Analysis for Triggered {RIP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2092,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="As required by Routing Protocol Criteria, this report
documents the key features of Triggered Extensions to RIP to Support
Demand Circuits and the current implementation experience. This document
is a product of the Routing Information Protocol Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2092.txt"
}

@TECHREPORT{rfc2093,
AUTHOR="H. Harney and C. Muckenhirn",
TITLE="Group Key Management Protocol {(GKMP)} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2093,
PAGES=23,
DAYS=15,
MONTH=jul,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2093.txt"
}

@TECHREPORT{rfc2094,
AUTHOR="H. Harney and C. Muckenhirn",
TITLE="Group Key Management Protocol {(GKMP)} Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2094,
PAGES=22,
DAYS=15,
MONTH=jul,
YEAR=1997,
ABSTRACT="This document describes an architecture for the management of
cryptographic keys for multicast communications. We identify the roles
and responsibilities of communications system elements in accomplishing
multicast key management, define security and functional requirements of
each, and provide a detailed introduction to the Group Key Management
Protocol (GKMP) which provides the ability to create and distribute keys
within arbitrary-sized groups without the intervention of a
global/centralized key manager.",
URL="http://www.rfc-editor.org/rfc/rfc2094.txt"
}

@TECHREPORT{rfc2095,
AUTHOR="J. Klensin and R. Catoe and P. Krumviede",
TITLE="{IMAP/POP} {AUTHorize} Extension for Simple {Challenge/Response}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2095,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2095.txt"
}

@TECHREPORT{rfc2096,
AUTHOR="F. Baker",
TITLE="{IP} Forwarding Table {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2096,
PAGES=21,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT={This memo defines an update to RFC 1354, {"}IP Forwarding Table
MIB{"}, for Classless Inter-Domain Routing (CIDR). That document was
developed by the Router Requirements Working Group as an update to RFC
1213's ipRouteTable, with the display of multiple routes as a primary
objective. The significant difference between this MIB and RFC 1354 is
the recognition (explicitly discussed but by consensus left to future
work) that CIDR routes may have the same network number but different
network masks. Note that this MIB obsoletes a number of objects from RFC
1354. This document is a product of the OSPF Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2096.txt"
}

@TECHREPORT{rfc2097,
AUTHOR="G. Pall",
TITLE="The {PPP} {NetBIOS} Frames Control Protocol {(NBFCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2097,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=1997,
ABSTRACT="This document defines the Network Control Protocol for
establishing and configuring the NBF protocol over PPP. This document is
a product of the Point-to-Point Protocol Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2097.txt"
}

@TECHREPORT{rfc2098,
AUTHOR="Y. Katsube and K. Nagami and H. Esaki",
TITLE="Toshiba's Router Architecture Extensions for {ATM} : Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2098,
PAGES=18,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2098.txt"
}

@TECHREPORT{rfc2099,
AUTHOR="J. Elliott",
TITLE="Request for Comments Summary {RFC} Numbers {2000-2099}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2099,
PAGES=21,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
2000 through RFCs 2099. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2099.txt"
}

@TECHREPORT{rfc2100,
AUTHOR="J. Ashworth",
TITLE="The Naming of Hosts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2100,
PAGES=3,
DAYS=15,
MONTH=apr,
YEAR=1997,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
2000 through RFCs 2099. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2100.txt"
}

@TECHREPORT{rfc2101,
AUTHOR="B. E. Carpenter and Jon Crowcroft and Y. Rekhter",
TITLE="{IPv4} Address Behaviour Today",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2101,
PAGES=13,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2101.txt"
}

@TECHREPORT{rfc2102,
AUTHOR="R. Ramanathan",
TITLE="Multicast Support for Nimrod : Requirements and Solution Approaches",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2102,
PAGES=23,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="Nimrod does not specify a particular solution for
multicasting. Rather, Nimrod may use any of a number of emerging
multicast techniques. This document identifies the requirements that
Nimrod has of a solution for multicast support. This document is a
product of the New Internet Routing and Addressing Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2102.txt"
}

@TECHREPORT{rfc2103,
AUTHOR="R. Ramanathan",
TITLE="Mobility Support for Nimrod : Challenges and Solution Approaches",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2103,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="This document discusses 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. This document
identifies the requirements that Nimrod has of any solution for mobility
support. It also classifies and compares existing approaches for
supporting mobility within an internetwork and discuss their advantages
and disadvantages. Finally, as an example, it outlines the mechanisms to
support mobility in Nimrod using the scheme currently being developed
within the IETF - namely, the Mobile-IP protocol. This document is the
product of the New Internet Routing and Addressing Architecture Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2103.txt"
}

@TECHREPORT{rfc2104,
AUTHOR="H. Krawczyk and M. Bellare and R. Canetti",
TITLE="{HMAC:} {Keyed-Hashing} for Message Authentication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2104,
PAGES=11,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="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. This document
is the product of the IP Security Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2104.txt"
}

@TECHREPORT{rfc2105,
AUTHOR="Y. Rekhter and B. S. Davie and D. Katz and E. C. Rosen and G. Swallow",
TITLE="Cisco Systems' Tag Switching Architecture Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2105,
PAGES=13,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="This document provides an overview of a novel approach to
network layer packet forwarding, called tag switching.",
URL="http://www.rfc-editor.org/rfc/rfc2105.txt"
}

@TECHREPORT{rfc2106,
AUTHOR="S. Chiang and J. Lee and H. Yasuda",
TITLE="Data Link Switching Remote Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2106,
PAGES=19,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2106.txt"
}

@TECHREPORT{rfc2107,
AUTHOR="K. Hamzeh",
TITLE="Ascend Tunnel Management Protocol - {ATMP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2107,
PAGES=21,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2107.txt"
}

@TECHREPORT{rfc2108,
AUTHOR="K. de Graaf and D. Romascanu and D. McMaster and K. McCloghrie",
TITLE="Definitions of Managed Objects for {IEEE} {802.3} Repeater Devices using
{SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2108,
PAGES=82,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT={This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing IEEE 802.3 10
and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30,
{"}10 \& 100 Mb/s Management,{"} October 26, 1995. This document is a
product
of the IEEE 802.3 Hub MIB Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2108.txt"
}

@TECHREPORT{rfc2109,
AUTHOR="D. Kristol and L. Montulli",
TITLE="{HTTP} State Management Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2109,
PAGES=21,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="This document specifies a way to create a stateful session
with HTTP requests and responses. It describes two new headers, Cookie
and Set-Cookie, which carry state information between participating
origin servers and user agents. This document is a product of the
HyperText Transfer Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2109.txt"
}

@TECHREPORT{rfc2110,
AUTHOR="J. Palme and A. Hopmann",
TITLE="{MIME} E-mail Encapsulation of Aggregate Documents, such as {HTML}
{(MHTML)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2110,
PAGES=19,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT={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 {"}Content- Location{"} and
{"}Content-Base{"}.},
URL="http://www.rfc-editor.org/rfc/rfc2110.txt"
}

@TECHREPORT{rfc2111,
AUTHOR="E. Levinson",
TITLE="{Content-ID} and {Message-ID} Uniform Resource Locators",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2111,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT={The Uniform Resource Locator (URL) schemes, {"}cid:{"} and {"}mid:{"}
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.},
URL="http://www.rfc-editor.org/rfc/rfc2111.txt"
}

@TECHREPORT{rfc2112,
AUTHOR="E. Levinson",
TITLE="The {MIME} {Multipart/Related} Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2112,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2112.txt"
}

@TECHREPORT{rfc2113,
AUTHOR="D. Katz",
TITLE="{IP} Router Alert Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2113,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2113.txt"
}

@TECHREPORT{rfc2114,
AUTHOR="S. Chiang and J. Lee and H. Yasuda",
TITLE="Data Link Switching Client Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2114,
PAGES=22,
DAYS=15,
MONTH=feb,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2114.txt"
}

@TECHREPORT{rfc2115,
AUTHOR="C. M. Brown and F. Baker",
TITLE="Management Information Base for Frame Relay {DTEs} Using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2115,
PAGES=32,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing Frame Relay
interfaces on DTEs.",
URL="http://www.rfc-editor.org/rfc/rfc2115.txt"
}

@TECHREPORT{rfc2116,
AUTHOR="C. Apple and K. Rossen",
TITLE="{X.500} Implementations Catalog-96",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2116,
PAGES=164,
DAYS=15,
MONTH=apr,
YEAR=1997,
ABSTRACT="This document contains detailed description of 31 X.500
implementations - DSAs, DUAs, and DUA interfaces. This document is a
product of the Integrated Directory Services Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2116.txt"
}

@TECHREPORT{rfc2117,
AUTHOR="D. Estrin and D. Farinacci and A. Helmy and D. Thaler and S. E. Deering and
M. Handley and V. Jacobson and C. Liu",
TITLE="Protocol Independent {Multicast-Sparse} Mode {(PIM-SM):} Protocol
Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2117,
PAGES=66,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="This document describes a protocol for efficiently routing to
multicast groups that may span wide-area (and inter-domain) internets.
This document is the product of the Inter-Domain Multicast Routing
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2117.txt"
}

@TECHREPORT{rfc2118,
AUTHOR="G. Pall",
TITLE="Microsoft {Point-To-Point} Compression {(MPPC)} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2118,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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. This document is the product
of the Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2118.txt"
}

@TECHREPORT{rfc2119,
AUTHOR="S. Bradner",
TITLE="Key words for use in {RFCs} to Indicate Requirement Levels",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2119,
PAGES=3,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2119.txt"
}

@TECHREPORT{rfc2120,
AUTHOR="D. Chadwick",
TITLE="Managing the {X.500} Root Naming Context",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2120,
PAGES=14,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="The X.500 Standard (X.500 93) 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. 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: firstly,
it is much easier to co-ordinate the management of the root context
information, when there is a central point of administration, 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. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2120.txt"
}

@TECHREPORT{rfc2121,
AUTHOR="G. Armitage",
TITLE="Issues affecting {MARS} Cluster Size",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2121,
PAGES=12,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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'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.",
URL="http://www.rfc-editor.org/rfc/rfc2121.txt"
}

@TECHREPORT{rfc2122,
AUTHOR="D. Mavrakis and H. Layec and K. Kartmann",
TITLE="{VEMMI} {URL} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2122,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT={A new URL scheme, {"}vemmi{"} is defined. It allows VEMMI client
software and VEMMI terminals to connect to multimedia interactive
services compliant to the VEMMI standard (Enhanced Man-Machine Interface
for Videotex and Multimedia/Hypermedia Information Retrieval Services),
sometimes abbreviated as {"}VErsatile MultiMedia Interface{"}. VEMMI is a
new international standard for on-line multimedia services, that is both
an ITU-T (International Telecommunications Union, ex. CCITT)
International Standard (T.107) and an European Standard (ETSI European
Telecommunications Standard Institute) standard (ETS 300 382, obsoleted
by ETS 300 709). VEMMI could be described as an on-line multimedia
protocol describing both the man-machine interface and the client/server
exchange protocol. VEMMI operates usually on a single continuous session
between a client and a host and supports an object-oriented, event-
driven, client/server oriented and platform independent multimedia
interface. The well-known tcp port number 575 has been assigned by IANA
to the VEMMI protocol. A description of the VEMMI standard along with
its last approved version is publicly available on the Web: see the URL
http://www.etsi.fr/ecs/projects/vemmi/vemmi.htm). A presentation of
VEMMI can be found on http://www.mctel.fr/VEMMI/vemmien\_intro.html},
URL="http://www.rfc-editor.org/rfc/rfc2122.txt"
}

@TECHREPORT{rfc2123,
AUTHOR="Nevil Brownlee",
TITLE="Traffic Flow Measurement: Experiences with {NeTraMet}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2123,
PAGES=34,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2123.txt"
}

@TECHREPORT{rfc2124,
AUTHOR="P. Amsden and J. Amweg and P. Calato and S. Bensley and G. Lyons",
TITLE="Cabletron's Light-weight Flow Admission Protocol Specification Version
{1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2124,
PAGES=21,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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.
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.",
URL="http://www.rfc-editor.org/rfc/rfc2124.txt"
}

@TECHREPORT{rfc2125,
AUTHOR="C. Richards and K. L. Smith",
TITLE="The {PPP} Bandwidth Allocation Protocol {(BAP)} / The {PPP} Bandwidth
Allocation Control Protocol {(BACP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2125,
PAGES=24,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2125.txt"
}

@TECHREPORT{rfc2126,
AUTHOR="Y. Pouffary and A. Young",
TITLE="{ISO} Transport Service on top of {TCP} {(ITOT)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2126,
PAGES=25,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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. 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2126.txt"
}

@TECHREPORT{rfc2127,
EDITOR="G. Roeck",
TITLE="{ISDN} Management Information Base using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2127,
PAGES=49,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines 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. 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. 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's mailing list at isdn-
mib(at)cisco.com and/or the author. The current version of this document
reflects changes made during the last call period and the IESG review.",
URL="http://www.rfc-editor.org/rfc/rfc2127.txt"
}

@TECHREPORT{rfc2128,
AUTHOR="G. Roeck and Witold Pedrycz",
TITLE="Dial Control Management Information Base using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2128,
PAGES=34,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
demand access circuits, including ISDN. 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. 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's mailing list at isdn-
mib(at)cisco.com and/or the author.",
URL="http://www.rfc-editor.org/rfc/rfc2128.txt"
}

@TECHREPORT{rfc2129,
AUTHOR="K. Nagami and Y. Katsube and Y. Shobatake and A. Mogi and S. Matsuzawa and
T. Jinmei and H. Esaki",
TITLE="Toshiba's Flow Attribute Notification Protocol {(FANP)} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2129,
PAGES=19,
DAYS=15,
MONTH=apr,
YEAR=1997,
ABSTRACT="This memo discusses Flow Attribute Notification Protocol
(FANP), which is a protocol between neighbor nodes for the management of
cut-through packet forwarding functionalities.",
URL="http://www.rfc-editor.org/rfc/rfc2129.txt"
}

@TECHREPORT{rfc2130,
AUTHOR="C. Weider and C. Preston and K. Simonsen and H. Alvestrand and R. Atkinson
and M. R. Crispin and P. Svanberg",
TITLE="The Report of the {IAB} Character Set Workshop held 29 February - 1 March,
1996",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2130,
PAGES=31,
DAYS=15,
MONTH=apr,
YEAR=1997,
ABSTRACT="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. This document is the product
of the Internet Architecture Board (IAB).",
URL="http://www.rfc-editor.org/rfc/rfc2130.txt"
}

@TECHREPORT{rfc2131,
AUTHOR="R. E. Droms",
TITLE="Dynamic Host Configuration Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2131,
PAGES=45,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT="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. This document is the product of the
Dynamic Host Configuration Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2131.txt"
}

@TECHREPORT{rfc2132,
AUTHOR="S. Alexander and R. E. Droms",
TITLE="{DHCP} Options and {BOOTP} Vendor Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2132,
PAGES=34,
DAYS=15,
MONTH=mar,
YEAR=1997,
ABSTRACT={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.{"}
This document specifies the current set of DHCP options. This document
is the product of the Dynamic Host Configuration Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2132.txt"
}

@TECHREPORT{rfc2133,
AUTHOR="R. Gilligan and S. Thomson and J. Bound and W. Richard Stevens",
TITLE="Basic Socket Interface Extensions for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2133,
PAGES=32,
DAYS=15,
MONTH=apr,
YEAR=1997,
ABSTRACT={The de facto standard application program interface (API) for
TCP/IP applications is the {"}sockets{"} interface. 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. This document is the product of the IPNG Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2133.txt"
}

@TECHREPORT{rfc2134,
AUTHOR=" {{ISOC Board of Trustees}}",
TITLE="Articles of Incorporation of Internet Society",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2134,
MONTH=apr,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2134.txt"
}

@TECHREPORT{rfc2135,
AUTHOR=" {{ISOC Board of Trustees}}",
TITLE="Internet Society {By-Laws}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2135,
MONTH=apr,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2135.txt"
}

@TECHREPORT{rfc2136,
AUTHOR="Paul  Vixie and Sue Thomson and Y. Rekhter and Jim Bound",
TITLE="Dynamic Updates in the Domain Name System {(DNS} {UPDATE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2136,
MONTH=apr,
YEAR=1997,
ABSTRACT="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's Master File.
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. This document is a product of the DNS IXFR,
Notification, and Dynamic Update Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2136.txt"
}

@TECHREPORT{rfc2137,
AUTHOR="D. Eastlake 3rd",
TITLE="Secure Domain Name System Dynamic Update",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2137,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=1997,
ABSTRACT="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's
possession of cryptographic keys. This document is the product of the
Domain Name System Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2137.txt"
}

@TECHREPORT{rfc2140,
AUTHOR="J. Touch",
TITLE="{TCP} Control Block Interdependence",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2140,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2140.txt"
}

@TECHREPORT{rfc2141,
AUTHOR="R. Moats",
TITLE="{URN} Syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2141,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT="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. This document is the product of the
Uniform Resource Names Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2141.txt"
}

@TECHREPORT{rfc2142,
AUTHOR="D. H. Crocker",
TITLE="Mailbox Names for Common Services, Roles and Functions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2142,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT="This specification enumerates and describes Internet mail
addresses (mailbox name (at) host reference) to be used when contacting
personnel at an organization.",
URL="http://www.rfc-editor.org/rfc/rfc2142.txt"
}

@TECHREPORT{rfc2143,
AUTHOR="B. Elliston",
TITLE="Encapsulating {IP} with the Small Computer System Interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2143,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT="This document outlines a protocol for connecting hosts running
the TCP/IP protocol suite over a Small Computer System Interface (SCSI)
bus.",
URL="http://www.rfc-editor.org/rfc/rfc2143.txt"
}

@TECHREPORT{rfc2144,
AUTHOR="C. J. Adams",
TITLE="The {CAST-128} Encryption Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2144,
PAGES=15,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT="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. This document
describes an existing algorithm that can be used to satisfy this
requirement.",
URL="http://www.rfc-editor.org/rfc/rfc2144.txt"
}

@TECHREPORT{rfc2145,
AUTHOR="J. C. Mogul and R. Fielding and J. Gettys and H. Frystyk",
TITLE="Use and Interpretation of {HTTP} Version Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2145,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT="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. This document is a product of the
HyperText Transfer Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2145.txt"
}

@TECHREPORT{rfc2146,
AUTHOR=" {{Federal Networking Council}}",
TITLE="{U.S.} Government Internet Domain Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2146,
MONTH=may,
YEAR=1997,
ABSTRACT={This memo provides an update and clarification to RFC 1816.
This document describes the registration policies for the top-level
domain {"}.GOV{"}.},
URL="http://www.rfc-editor.org/rfc/rfc2146.txt"
}

@TECHREPORT{rfc2147,
AUTHOR="D. Borman",
TITLE="{TCP} and {UDP} over {IPv6} Jumbograms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2147,
PAGES=3,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT="This document describes some simple changes that can be made
to allow TCP and UDP to make use of IPv6 jumbograms. This document is a
product of the IPng Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2147.txt"
}

@TECHREPORT{rfc2148,
AUTHOR="H. Alvestrand and P. Jurg",
TITLE="Deployment of the Internet White Pages Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2148,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This document describes the way in which the Internet White
Pages Service (from now on abbreviated as IWPS) is best exploited using
today's experience, today's protocols, today's products and today's
procedures.",
URL="http://www.rfc-editor.org/rfc/rfc2148.txt"
}

@TECHREPORT{rfc2149,
AUTHOR="R. Talpade and M. Ammar",
TITLE="Multicast Server Architectures for {MARS-based} {ATM} multicasting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2149,
PAGES=18,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT="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 'VC Mesh' 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 document is the product of the Internetworking Over NBMA
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2149.txt"
}

@TECHREPORT{rfc2150,
AUTHOR="J. Max and W. Stickle",
TITLE="Humanities and Arts: Sharing Center Stage on the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2150,
PAGES=62,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2150.txt"
}

@TECHREPORT{rfc2151,
AUTHOR="G. Kessler and S. Shepard",
TITLE="A Primer On Internet and {TCP/IP} Tools and Utilities",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2151,
PAGES=52,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2151.txt"
}

@TECHREPORT{rfc2152,
AUTHOR="D. Goldsmith and M. Davis",
TITLE="{UTF-7} A {Mail-Safe} Transformation Format of Unicode",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2152,
PAGES=15,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT={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, {"}Using Unicode with
MIME{"}.},
URL="http://www.rfc-editor.org/rfc/rfc2152.txt"
}

@TECHREPORT{rfc2153,
AUTHOR="W. Simpson",
TITLE="{PPP} Vendor Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2153,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1997,
ABSTRACT="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. This document defines a general
mechanism for proprietary vendor extensions. This document is a product
of the Point-to-Point Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2153.txt"
}

@TECHREPORT{rfc2154,
AUTHOR="S. Murphy and M. Badger and B. Wellington",
TITLE="{OSPF} with Digital Signatures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2154,
PAGES=29,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2154.txt"
}

@TECHREPORT{rfc2155,
AUTHOR="B. Clouston and B. W. Moore",
TITLE="Definitions of Managed Objects for {APPN} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2155,
PAGES=124,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for monitoring and
controlling network devices with APPN (Advanced Peer-to-Peer Networking)
capabilities. This memo identifies managed objects for the APPN
protocol. This document is the product of the SNA NAU Services MIB
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2155.txt"
}

@TECHREPORT{rfc2165,
AUTHOR="J. Veizades and E. Guttman and C. E. Perkins and S. M. Kaplan",
TITLE="Service Location Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2165,
PAGES=72,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="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
document is a product of the Service Location Protocol Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2165.txt"
}

@TECHREPORT{rfc2166,
AUTHOR="D. Bryant and P. Brittain",
TITLE="{APPN} Implementer's Workshop Closed Pages Document {DLSw} v2.0
Enhancements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2166,
PAGES=34,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="This document specifies a set of extensions to RFC 1795
designed to improve the scalability of DLSw. It also specifies
clarifications to RFC 1795 in the light of the implementation experience
to-date.",
URL="http://www.rfc-editor.org/rfc/rfc2166.txt"
}

@TECHREPORT{rfc2167,
AUTHOR="S. Williamson and M. Kosters and D. Blacka and J. Singh and K. Zeilstra",
TITLE="Referral Whois {(RWhois)} Protocol {V1.5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2167,
PAGES=69,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2167.txt"
}

@TECHREPORT{rfc2168,
AUTHOR="R. W. Daniel and M. Mealling",
TITLE="Resolution of Uniform Resource Identifiers using the Domain Name System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2168,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT={The requirements document for URN resolution systems defines
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. This document is a product of the
Uniform Resource Names Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2168.txt"
}

@TECHREPORT{rfc2169,
AUTHOR="R. W. Daniel",
TITLE="A Trivial Convention for using {HTTP} in {URN} Resolution",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2169,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT={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. This document is a product of
Uniform Resource Names Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2169.txt"
}

@TECHREPORT{rfc2170,
AUTHOR="W. Almesberger and Jean-Yves Le Boudec and P. Oechslin",
TITLE="Application {REQuested} {IP} over {ATM} {(AREQUIPA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2170,
PAGES=10,
DAYS=15,
MONTH=jul,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2170.txt"
}

@TECHREPORT{rfc2171,
AUTHOR="K. Murakami and M. Maruyama",
TITLE="{MAPOS} - Multiple Access Protocol over {SONET/SDH} Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2171,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="This document describes the protocol MAPOS, Multiple Access
Protocol over SONET/SDH, for transmitting network-protocol datagrams
over SONET/SDH.",
URL="http://www.rfc-editor.org/rfc/rfc2171.txt"
}

@TECHREPORT{rfc2172,
AUTHOR="M. Maruyama and K. Murakami",
TITLE="{MAPOS} Version 1 Assigned Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2172,
PAGES=3,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="This document describes the protocol parameters used in the
Multiple Access Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer
protocol and provides multiple access capability over SONET/SDH links.",
URL="http://www.rfc-editor.org/rfc/rfc2172.txt"
}

@TECHREPORT{rfc2173,
AUTHOR="K. Murakami and M. Maruyama",
TITLE="A {MAPOS} version 1 Extension - Node Switch Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2173,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2173.txt"
}

@TECHREPORT{rfc2174,
AUTHOR="K. Murakami and M. Maruyama",
TITLE="A {MAPOS} version 1 Extension - {Switch-Switch} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2174,
PAGES=22,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2174.txt"
}

@TECHREPORT{rfc2175,
AUTHOR="K. Murakami and M. Maruyama",
TITLE="{MAPOS} 16 - Multiple Access Protocol over {SONET/SDH} with 16 Bit
Addressing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2175,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="This memo documents MAPOS 16, a multiple access protocol for
transmission of network-protocol datagrams, encapsulated in HDLC frames
with 16 bit addressing, over SONET/SDH.",
URL="http://www.rfc-editor.org/rfc/rfc2175.txt"
}

@TECHREPORT{rfc2176,
AUTHOR="K. Murakami and M. Maruyama",
TITLE="{IPv4} over {MAPOS} Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2176,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="This document describes a protocol for transmission of the
Internet Protocol Version 4 (IPv4) over Multiple Access Over SONET/SDH
(MAPOS) version 1. MAPOS is a link layer protocol and provides multiple
access capability over SONET/SDH links. IP runs on top of MAPOS. This
document explains IP datagram encapsulation in HDLC frame of MAPOS, and
the Address Resolution Protocol (ARP).",
URL="http://www.rfc-editor.org/rfc/rfc2176.txt"
}

@TECHREPORT{rfc2177,
AUTHOR="B. Leiba",
TITLE="{IMAP4} {IDLE} command",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2177,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=1997,
ABSTRACT="The Internet Message Access Protocol (IMAP4) requires a client
to poll the server for changes to the selected mailbox (new mail,
deletions). It's often more desirable to have the server transmit
updates to the client in real time. This document specifies the syntax
of an IDLE command, which will allow a client to tell the server that
it's ready to accept such real-time updates.",
URL="http://www.rfc-editor.org/rfc/rfc2177.txt"
}

@TECHREPORT{rfc2178,
AUTHOR="J. Moy",
TITLE="{OSPF} Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2178,
PAGES=211,
DAYS=15,
MONTH=jul,
YEAR=1997,
ABSTRACT="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. This document is a product of the Open
Shortest Path First IGP (ospf) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2178.txt"
}

@TECHREPORT{rfc2179,
AUTHOR="A. Gwinn",
TITLE="Network Security For Trade Shows",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2179,
PAGES=10,
DAYS=15,
MONTH=jul,
YEAR=1997,
ABSTRACT="This document is designed to assist vendors and other
participants in trade shows in designing effective protection against
network and system attacks by unauthorized individuals.",
URL="http://www.rfc-editor.org/rfc/rfc2179.txt"
}

@TECHREPORT{rfc2180,
AUTHOR="M. Gahrns",
TITLE="{IMAP4} {Multi-Accessed} Mailbox Practice",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2180,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=1997,
ABSTRACT="IMAP4 is rich client/server protocol that allows a client to
access and manipulate electronic mail messages on a server. By
documenting common IMAP4 server practice for the case of simultaneous
client access to a mailbox, the authors hope to ensure the widest amount
of inter-operation between IMAP4 clients and servers.",
URL="http://www.rfc-editor.org/rfc/rfc2180.txt"
}

@TECHREPORT{rfc2181,
AUTHOR="R. Elz and R. Bush",
TITLE="Clarifications to the {DNS} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2181,
PAGES=15,
DAYS=15,
MONTH=jul,
YEAR=1997,
ABSTRACT="This document considers some areas that have been identified
as problems with the specification of the Domain Name System, and
proposes remedies for the defects identified. This document is a product
of the DNS IXFR, Notification, and Dynamic Update Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2181.txt"
}

@TECHREPORT{rfc2182,
AUTHOR="R. Elz and R. Bush and S. Bradner and M. Patton",
TITLE="Selection and Operation of Secondary {DNS} Servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2182,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1997,
ABSTRACT="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. This document is a product of the
DNS IXFR, Notification, and Dynamic Update Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2182.txt"
}

@TECHREPORT{rfc2183,
AUTHOR="R. Troost and S. Dorner and K. Moore and Witold Pedrycz",
TITLE="Communicating Presentation Information in Internet Messages: The
{Content-Disposition} Header Field",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2183,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=1997,
ABSTRACT={This memo provides a mechanism whereby messages conforming to
the MIME specifications (RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
2049) can convey presentational information. It specifies the
{"}Content-Disposition{"} header field, which is optional and valid for any
MIME entity ({"}message{"} or {"}body part{"}).},
URL="http://www.rfc-editor.org/rfc/rfc2183.txt"
}

@TECHREPORT{rfc2184,
AUTHOR="N. Freed and K. Moore",
TITLE="{MIME} Parameter Value and Encoded Word Extensions: Character Sets,
Languages, and Continuations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2184,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1997,
ABSTRACT="This memo defines extensions to the RFC 2045 media type and
RFC 2183 disposition parameter value mechanisms and also defines an
extension to the encoded words defined in RFC 2047 to allow the
specification of the language to be used for display as well as the
character set.",
URL="http://www.rfc-editor.org/rfc/rfc2184.txt"
}

@TECHREPORT{rfc2185,
AUTHOR="R. Callon and D. Haskin",
TITLE="Routing Aspects of {IPv6} Transition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2185,
PAGES=13,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT={This document gives an overview of the routing aspects of the
IPv6 transition. It is based on the protocols defined in the document
{"}Transition Mechanisms for IPv6 Hosts and Routers{"}. Readers should be
familiar with the transition mechanisms before reading this document.},
URL="http://www.rfc-editor.org/rfc/rfc2185.txt"
}

@TECHREPORT{rfc2186,
AUTHOR="D. Wessels and K. Claffy",
TITLE="Internet Cache Protocol {(ICP),} version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2186,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This document describes version 2 of the Internet Cache
Protocol (ICPv2) as currently implemented in two World-Wide Web proxy
cache packages.",
URL="http://www.rfc-editor.org/rfc/rfc2186.txt"
}

@TECHREPORT{rfc2187,
AUTHOR="D. Wessels and K. Claffy",
TITLE="Application of Internet Cache Protocol {(ICP),} version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2187,
PAGES=24,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This document describes the application of ICPv2 (Internet
Cache Protocol version 2, RFC2186) to Web caching.",
URL="http://www.rfc-editor.org/rfc/rfc2187.txt"
}

@TECHREPORT{rfc2188,
AUTHOR="M. Banan and M. C. Taylor and J. Cheng",
TITLE="{AT\&T/Neda's} Efficient Short Remote Operations {(ESRO)} Protocol
Specification Version {1.2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2188,
PAGES=57,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2188.txt"
}

@TECHREPORT{rfc2189,
AUTHOR="A. Ballardie",
TITLE="Core Based Trees {(CBT} version {2)} Multicast Routing {--} Protocol
Specification {--}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2189,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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. 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 RFC 2201.",
URL="http://www.rfc-editor.org/rfc/rfc2189.txt"
}

@TECHREPORT{rfc2190,
AUTHOR="C. Zhu",
TITLE="{RTP} Payload Format for {H.263} Video Streams",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2190,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This document specifies the payload format for encapsulating
an H.263 bitstream in the Real-Time Transport Protocol (RTP).",
URL="http://www.rfc-editor.org/rfc/rfc2190.txt"
}

@TECHREPORT{rfc2191,
AUTHOR="G. Armitage",
TITLE="{VENUS} - Very Extensive {Non-Unicast} Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2191,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT={This document focuses exclusively on the problems associated
with extending the MARS model (RFC2022) to cover multiple clusters or
clusters spanning more than one subnet. It describes a hypothetical
solution, dubbed {"}Very Extensive NonUnicast Service{"} (VENUS), and shows
how complex such a service would be.},
URL="http://www.rfc-editor.org/rfc/rfc2191.txt"
}

@TECHREPORT{rfc2192,
AUTHOR="C. Newman",
TITLE="{IMAP} {URL} Scheme",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2192,
PAGES=16,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2192.txt"
}

@TECHREPORT{rfc2193,
AUTHOR="M. Gahrns",
TITLE="{IMAP4} Mailbox Referrals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2193,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="When dealing with large amounts of users, messages and
geographically dispersed IMAP4 (RFC-2060) servers, it is often desirable
to distribute messages amongst different servers within an organization.
Mailbox referrals allow clients to seamlessly access mailboxes that are
distributed across several IMAP4 servers.",
URL="http://www.rfc-editor.org/rfc/rfc2193.txt"
}

@TECHREPORT{rfc2194,
AUTHOR="B. Aboba and J. Lu and J. Alsop and J. Ding and W. Wang",
TITLE="Review of Roaming Implementations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2194,
PAGES=35,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This document reviews the design and functionality of existing
roaming implementations.",
URL="http://www.rfc-editor.org/rfc/rfc2194.txt"
}

@TECHREPORT{rfc2196,
AUTHOR="B. Fraser",
TITLE="Site Security Handbook",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2196,
PAGES=75,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2196.txt"
}

@TECHREPORT{rfc2197,
AUTHOR="N. Freed",
TITLE="{SMTP} Service Extension for Command Pipelining",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2197,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2197.txt"
}

@TECHREPORT{rfc2198,
AUTHOR="C. E. Perkins and I. Kouvelas and O. Hodson and V. J. Hardman and M.
Handley and J. C. Bolot and A. Vega-Garcia and S. Fosse-Parisis",
TITLE="{RTP} Payload for Redundant Audio Data",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2198,
PAGES=11,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This document describes a payload format for use with the
real-time transport protocol (RTP), version 2, for encoding redundant
audio data.",
URL="http://www.rfc-editor.org/rfc/rfc2198.txt"
}

@TECHREPORT{rfc2201,
AUTHOR="A. Ballardie",
TITLE="Core Based Trees {(CBT)} Multicast Routing Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2201,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="CBT is a multicast routing architecture that builds a single
delivery tree per group which is shared by all of the group's senders
and receivers. Most multicast algorithms build one multicast tree per
sender (subnetwork), the tree being rooted at the sender's subnetwork.
The primary advantage of the shared tree approach is that it typically
offers more favourable scaling characteristics than all other multicast
algorithms. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2201.txt"
}

@TECHREPORT{rfc2202,
AUTHOR="P. S. Cheng and R. Glenn",
TITLE="Test Cases for {HMAC-MD5} and {HMAC-SHA-1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2202,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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 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.",
URL="http://www.rfc-editor.org/rfc/rfc2202.txt"
}

@TECHREPORT{rfc2203,
AUTHOR="M. Eisler and A. Chiu and L. Ling",
TITLE="{RPCSEC\\_GSS} Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2203,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2203.txt"
}

@TECHREPORT{rfc2204,
AUTHOR="D. Nash",
TITLE="{ODETTE} File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2204,
PAGES=74,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This memo describes a file transfer protocol to facilitate
electronic data interchange between trading partners. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2204.txt"
}

@TECHREPORT{rfc2205,
EDITOR="R. Braden and L. Zhang and S. Berson",
TITLE="Resource {ReSerVation} Protocol {(RSVP)} {--} Version 1 Functional
Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2205,
PAGES=112,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This memo describes version 1 of RSVP, a resource reservation
setup protocol designed for an integrated services Internet. RSVP
provides receiver-initiated setup of resource reservations for multicast
or unicast data flows, with good scaling and robustness properties.",
URL="http://www.rfc-editor.org/rfc/rfc2205.txt"
}

@TECHREPORT{rfc2206,
AUTHOR="F. Baker and J. Krawczyk and A. Sastry",
TITLE="{RSVP} Management Information Base using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2206,
PAGES=64,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the Resource
Reservation Protocol (RSVP) within the interface attributes defined in
the Integrated Services Model. Thus, the Integrated Services MIB is
directly relevant to and cross-referenced by this MIB. Comments should
be made to the RSVP Working Group, rsvp(at)isi.edu.",
URL="http://www.rfc-editor.org/rfc/rfc2206.txt"
}

@TECHREPORT{rfc2207,
AUTHOR="L. Berger and T. O'Malley",
TITLE="{RSVP} Extensions for {IPSEC} Data Flows",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2207,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This document presents extensions to Version 1 of RSVP. These
extensions permit support of individual data flows using RFC 1826, IP
Authentication Header (AH) or RFC 1827, IP Encapsulating Security
Payload (ESP). RSVP Version 1 as currently specified can support the
IPSEC protocols, but only on a per address, per protocol basis not on a
per flow basis. The presented extensions can be used with both IPv4 and
IPv6.",
URL="http://www.rfc-editor.org/rfc/rfc2207.txt"
}

@TECHREPORT{rfc2208,
EDITOR="Allison Mankin and F. Baker and B. Braden",
TITLE="Resource {ReSerVation} Protocol {(RSVP)} {--} Version 1 Applicability
Statement Some Guidelines on Deployment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2208,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2208.txt"
}

@TECHREPORT{rfc2209,
AUTHOR="R. Braden and L. Zhang",
TITLE="Resource {ReSerVation} Protocol {(RSVP)} {--} Version 1 Message Processing
Rules",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2209,
PAGES=25,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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. This memo provides
a generic description of the rules for the operation of Version 1 of
RSVP (RFC 2205). It is intended to outline a set of algorithms that will
accomplish the needed function, omitting many details.",
URL="http://www.rfc-editor.org/rfc/rfc2209.txt"
}

@TECHREPORT{rfc2210,
AUTHOR="J. Wroclawski",
TITLE="The Use of {RSVP} with {IETF} Integrated Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2210,
PAGES=33,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2210.txt"
}

@TECHREPORT{rfc2211,
AUTHOR="J. Wroclawski",
TITLE="Specification of the {Controlled-Load} Network Element Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2211,
PAGES=19,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2211.txt"
}

@TECHREPORT{rfc2212,
AUTHOR="S. Shenker and C. Partridge and R. Guerin",
TITLE="Specification of Guaranteed Quality of Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2212,
PAGES=20,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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 RFC 2216.",
URL="http://www.rfc-editor.org/rfc/rfc2212.txt"
}

@TECHREPORT{rfc2213,
AUTHOR="F. Baker and J. Krawczyk and A. Sastry",
TITLE="Integrated Services Management Information Base using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2213,
PAGES=21,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the the
interface attributes defined in the Integrated Services Model. Comments
should be made to the Integrated Services Working Group,
int-serv(at)isi.edu.",
URL="http://www.rfc-editor.org/rfc/rfc2213.txt"
}

@TECHREPORT{rfc2214,
AUTHOR="F. Baker and J. Krawczyk and A. Sastry",
TITLE="Integrated Services Management Information Base Guaranteed Service
Extensions using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2214,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the the
interface attributes defined in the Guaranteed Service of the Integrated
Services Model. Comments should be made to the Integrated Services
Working Group, intserv(at)isi.edu.",
URL="http://www.rfc-editor.org/rfc/rfc2214.txt"
}

@TECHREPORT{rfc2215,
AUTHOR="S. Shenker and J. Wroclawski",
TITLE="General Characterization Parameters for Integrated Service Network Elements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2215,
PAGES=16,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2215.txt"
}

@TECHREPORT{rfc2216,
AUTHOR="S. Shenker and J. Wroclawski",
TITLE="Network Element Service Specification Template",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2216,
PAGES=22,
DAYS=15,
MONTH=sep,
YEAR=1997,
ABSTRACT="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 'template' which
service specification documents should follow. The specification
template includes per-element requirements such as the service'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).",
URL="http://www.rfc-editor.org/rfc/rfc2216.txt"
}

@TECHREPORT{rfc2217,
AUTHOR="G. M. Clark",
TITLE="Telnet Com Port Control Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2217,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="This memo proposes a protocol to allow greater use of modems
attached to a network for outbound dialing purposes.",
URL="http://www.rfc-editor.org/rfc/rfc2217.txt"
}

@TECHREPORT{rfc2218,
AUTHOR="T. Genovese and B. Jennings",
TITLE="A Common Schema for the Internet White Pages Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2218,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2218.txt"
}

@TECHREPORT{rfc2219,
AUTHOR="M. Hamilton and R. Wright",
TITLE="Use of {DNS} Aliases for Network Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2219,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="It has become a common practice to use symbolic names (usually
CNAMEs) in the Domain Name Service (DNS - RFC 1034, RFC 1035) to refer
to network services such as anonymous FTP (RFC-959) servers, Gopher
(RFC-1436) servers, and most notably World-Wide Web HTTP (RFC-1945)
servers. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2219.txt"
}

@TECHREPORT{rfc2220,
AUTHOR="R. Guenther",
TITLE="The {Application/MARC} Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2220,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2220.txt"
}

@TECHREPORT{rfc2221,
AUTHOR="M. Gahrns",
TITLE="{IMAP4} Login Referrals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2221,
PAGES=5,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="When dealing with large amounts of users and many IMAP4
(RFC-2060) servers, it is often necessary to move users from one IMAP4
server to another. For example, hardware failures or organizational
changes may dictate such a move. Login referrals allow clients to
transparently connect to an alternate IMAP4 server, if their home IMAP4
server has changed.",
URL="http://www.rfc-editor.org/rfc/rfc2221.txt"
}

@TECHREPORT{rfc2222,
AUTHOR="J. Myers",
TITLE="Simple Authentication and Security Layer {(SASL)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2222,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="This document describes a method for adding authentication
support to connection-based protocols. To use this specification, a
protocol includes a command for identifying and authenticating a user to
a server and for optionally negotiating protection of subsequent
protocol interactions. If its use is negotiated, a security layer is
inserted between the protocol and the connection. This document
describes how a protocol specifies such a command, defines several
mechanisms for use by the command, and defines the protocol used for
carrying a negotiated security layer over the connection.",
URL="http://www.rfc-editor.org/rfc/rfc2222.txt"
}

@TECHREPORT{rfc2223,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Instructions to {RFC} Authors",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2223,
PAGES=20,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="This Request for Comments (RFC) provides information about the
preparation of RFCs, and certain policies relating to the publication of
RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2223.txt"
}

@TECHREPORT{rfc2224,
AUTHOR="B. Callaghan",
TITLE="{NFS} {URL} Scheme",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2224,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT={A new URL scheme, 'nfs' is defined. It is used to refer to
files and directories on NFS servers using the general URL syntax
defined in RFC 1738, {"}Uniform Resource Locators (URL){"}.},
URL="http://www.rfc-editor.org/rfc/rfc2224.txt"
}

@TECHREPORT{rfc2226,
AUTHOR="T. R. Smith and G. Armitage",
TITLE="{IP} Broadcast over {ATM} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2226,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2226.txt"
}

@TECHREPORT{rfc2227,
AUTHOR="J. C. Mogul and P. J. Leach",
TITLE="Simple {Hit-Metering} and {Usage-Limiting} for {HTTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2227,
PAGES=37,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT={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.{"}},
URL="http://www.rfc-editor.org/rfc/rfc2227.txt"
}

@TECHREPORT{rfc2228,
AUTHOR="M. Horowitz and S. J. Lunt",
TITLE="{FTP} Security Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2228,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT={This document defines extensions to the FTP specification STD
9, RFC 959, {"}File transfer protocol (FTP){"} (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.},
URL="http://www.rfc-editor.org/rfc/rfc2228.txt"
}

@TECHREPORT{rfc2229,
AUTHOR="R. Faith and B. Martin",
TITLE="A Dictionary Server Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2229,
PAGES=30,
DAYS=15,
MONTH=oct,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2229.txt"
}

@TECHREPORT{rfc2230,
AUTHOR="R. Atkinson",
TITLE="Key Exchange Delegation Record for the {DNS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2230,
PAGES=11,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2230.txt"
}

@TECHREPORT{rfc2232,
EDITOR="B. Clouston and I. W. Ed. and B. W. Moore",
TITLE="Definitions of Managed Objects for {DLUR} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2232,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for monitoring and
controlling network devices with DLUR (Dependent LU Requester)
capabilities. This memo identifies managed objects for the DLUR
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2232.txt"
}

@TECHREPORT{rfc2233,
AUTHOR="K. McCloghrie and F. Kastenholz",
TITLE="The Interfaces Group {MIB} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2233,
PAGES=66,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
Network Interfaces.",
URL="http://www.rfc-editor.org/rfc/rfc2233.txt"
}

@TECHREPORT{rfc2234,
EDITOR="D. H. Crocker and P. Overell",
TITLE="Augmented {BNF} for Syntax Specifications: {ABNF}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2234,
PAGES=14,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="Internet technical specifications often need to define a
format syntax and are free to employ whatever notation their authors
deem useful. Over the years, a modified version of Backus-Naur Form
(BNF), called Augmented BNF (ABNF), has been popular among many Internet
specifications. It balances compactness and simplicity, with reasonable
representational power. In the early days of the Arpanet, each
specification contained its own definition of ABNF. This included the
email specifications, RFC733 and then RFC822 which have come to be the
common citations for defining ABNF. The current document separates out
that definition, to permit selective reference.",
URL="http://www.rfc-editor.org/rfc/rfc2234.txt"
}

@TECHREPORT{rfc2235,
AUTHOR="R. Zakon",
TITLE="Hobbes' Internet Timeline",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2235,
PAGES=22,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="This document presents a history of the Internet in timeline
fashion, highlighting some of the key events and technologies which
helped shape the Internet as we know it today. A growth summary of the
Internet and some associated technologies is also included.",
URL="http://www.rfc-editor.org/rfc/rfc2235.txt"
}

@TECHREPORT{rfc2236,
AUTHOR="W. Fenner",
TITLE="Internet Group Management Protocol, Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2236,
PAGES=24,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="This memo documents IGMPv2, used by IP hosts to report their
multicast group memberships to routers. It updates STD 5, RFC 1112.
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.",
URL="http://www.rfc-editor.org/rfc/rfc2236.txt"
}

@TECHREPORT{rfc2237,
AUTHOR="K. Tamaru",
TITLE="Japanese Character Encoding for Internet Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2237,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT={This memo defines an encoding scheme for the Japanese
Characters, describes {"}ISO-2022-JP-1{"}, which is used in electronic mail
(RFC 822), and network news (RFC 1036). Also this memo provides a
listing of the Japanese Character Set that can be used in this encoding
scheme.},
URL="http://www.rfc-editor.org/rfc/rfc2237.txt"
}

@TECHREPORT{rfc2238,
EDITOR="B. Clouston and I. W. Ed. and B. W. Moore",
TITLE="Definitions of Managed Objects for {HPR} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2238,
PAGES=35,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for monitoring and
controlling network devices with HPR (High Performance Routing)
capabilities. This memo identifies managed objects for the HPR protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2238.txt"
}

@TECHREPORT{rfc2239,
AUTHOR="K. de Graaf and D. Romascanu and D. McMaster and K. McCloghrie and S. D.
Roberts",
TITLE="Definitions of Managed Objects for {IEEE} {802.3} Medium Attachment Units
{(MAUs)} using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2239,
PAGES=43,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT={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, {"}10 \& 100 Mb/s Management,{"} October 26, 1995.},
URL="http://www.rfc-editor.org/rfc/rfc2239.txt"
}

@TECHREPORT{rfc2240,
AUTHOR="O. Vaughan",
TITLE="A Legal Basis for Domain Name Allocation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2240,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="The purpose of this memo is to focus discussion on the
particular problems with the exhaustion of the top level domain space in
the Internet and the possible conflicts that can occur when multiple
organisations are vying for the same name. No proposed solutions in this
document are intended as standards for the Internet. Rather, it is hoped
that a general consensus will emerge as to the appropriate solution to
such problems, leading eventually to the adoption of standards.",
URL="http://www.rfc-editor.org/rfc/rfc2240.txt"
}

@TECHREPORT{rfc2241,
AUTHOR="D. Provan",
TITLE="{DHCP} Options for Novell Directory Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2241,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="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'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.",
URL="http://www.rfc-editor.org/rfc/rfc2241.txt"
}

@TECHREPORT{rfc2242,
AUTHOR="R. E. Droms and K. Fong",
TITLE="{NetWare/IP} Domain Name and Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2242,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="The Dynamic Host Configuration Protocol (DHCP) (RFC 2131)
provides a framework for passing configuration information to hosts on a
TCP/IP network. DHCP includes options for specific configuration
parameters (RFC 2132). This document defines options that carry
NetWare/IP domain name and NetWare/IP sub-options to DHCP clients.",
URL="http://www.rfc-editor.org/rfc/rfc2242.txt"
}

@TECHREPORT{rfc2243,
AUTHOR="C. Metz",
TITLE="{OTP} Extended Responses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2243,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT="This document provides a specification for a type of response
to an OTP (RFC 1938) challenge that carries explicit indication of the
response's encoding. Codings for the two mandatory OTP data formats
using this new type of response are presented. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2243.txt"
}

@TECHREPORT{rfc2244,
AUTHOR="C. Newman and J. Myers",
TITLE="{ACAP} {--} Application Configuration Access Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2244,
PAGES=68,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2244.txt"
}

@TECHREPORT{rfc2245,
AUTHOR="C. Newman",
TITLE="Anonymous {SASL} Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2245,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=1997,
ABSTRACT={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 {"}anonymous{"} 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.},
URL="http://www.rfc-editor.org/rfc/rfc2245.txt"
}

@TECHREPORT{rfc2251,
AUTHOR="M. Wahl and T. Howes and S. E. Kille",
TITLE="Lightweight Directory Access Protocol (v3)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2251,
PAGES=50,
DAYS=15,
MONTH=dec,
YEAR=1997,
ABSTRACT="The protocol described in this document is designed to provide
access to directories supporting the X.500 models, while not incurring
the resource requirements of the X.500 Directory Access Protocol (DAP).
This protocol is specifically targeted at management applications and
browser applications that provide read/write interactive access to
directories. When used with a directory supporting the X.500 protocols,
it is intended to be a complement to the X.500 DAP.",
URL="http://www.rfc-editor.org/rfc/rfc2251.txt"
}

@TECHREPORT{rfc2252,
AUTHOR="M. Wahl and A. Coulbeck and T. Howes and S. E. Kille",
TITLE="Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2252,
PAGES=32,
DAYS=15,
MONTH=dec,
YEAR=1997,
ABSTRACT="The Lightweight Directory Access Protocol (LDAP) equires that
the contents of AttributeValue fields in protocol elements be octet
strings. This document defines a set of syntaxes for LDAPv3, and the
rules by which attribute values of these syntaxes are represented as
octet strings for transmission in the LDAP protocol. The syntaxes
defined in this document are referenced by this and other documents that
define attribute types. This document also defines the set of attribute
types which LDAP servers should support.",
URL="http://www.rfc-editor.org/rfc/rfc2252.txt"
}

@TECHREPORT{rfc2253,
AUTHOR="M. Wahl and S. E. Kille and T. Howes",
TITLE="Lightweight Directory Access Protocol (v3): {UTF-8} String Representation
of Distinguished Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2253,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1997,
ABSTRACT="The X.500 Directory uses distinguished names as the primary
keys to entries in the directory. Distinguished Names are encoded in
ASN.1 in the X.500 Directory protocols. In the Lightweight Directory
Access Protocol, a string representation of distinguished names is
transferred. This specification defines the string format for
representing names, which is designed to give a clean representation of
commonly used distinguished names, while being able to represent any
distinguished name.",
URL="http://www.rfc-editor.org/rfc/rfc2253.txt"
}

@TECHREPORT{rfc2254,
AUTHOR="T. Howes",
TITLE="The String Representation of {LDAP} Search Filters",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2254,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=1997,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2254.txt"
}

@TECHREPORT{rfc2255,
AUTHOR="T. Howes and M. Smith",
TITLE="The {LDAP} {URL} Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2255,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1997,
ABSTRACT="LDAP is the Lightweight Directory Access Protocol. This
document describes a format for an LDAP Uniform Resource Locator. The
format describes an LDAP search operation to perform to retrieve
information from an LDAP directory. This document replaces RFC 1959. It
updates the LDAP URL format for version 3 of LDAP and clarifies how LDAP
URLs are resolved. This document also defines an extension mechanism for
LDAP URLs, so that future documents can extend their functionality, for
example, to provide access to new LDAPv3 extensions as they are defined.",
URL="http://www.rfc-editor.org/rfc/rfc2255.txt"
}

@TECHREPORT{rfc2256,
AUTHOR="M. Wahl",
TITLE="A Summary of the {X.500(96)} User Schema for use with {LDAPv3}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2256,
PAGES=20,
DAYS=15,
MONTH=dec,
YEAR=1997,
ABSTRACT="This document provides an overview of the attribute types and
object classes defined by the ISO and ITU-T committees in the X.500
documents, in particular those intended for use by directory clients.
This is the most widely used schema for LDAP/X.500 directories, and many
other schema definitions for white pages objects use it as a basis. This
document does not cover attributes used for the administration of X.500
directory servers, nor does it include attributes defined by other
ISO/ITU-T documents.",
URL="http://www.rfc-editor.org/rfc/rfc2256.txt"
}

@TECHREPORT{Rign9704:Remote,
AUTHOR="C. Rigney and A. Rubens and W. Simpson and S. Willens",
TITLE="Remote Authentication Dial In User Service {{(RADIUS)}}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
MONTH=apr,
YEAR=1997,
URL="http://www.rfc-editor.org/rfc/rfc2138.txt"
}

@TECHREPORT{rfc2156,
AUTHOR="S. E. Kille",
TITLE="{MIXER} (Mime Internet {X.400} Enhanced Relay): Mapping between {X.400} and
{RFC} {822/MIME}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2156,
PAGES=144,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT={This document relates primarily to the ITU-T 1988 and 1992
X.400 Series Recommendations / ISO IEC 10021 International Standard.
This ISO/ITU-T standard is referred to in this document as {"}X.400{"},
which is a convenient shorthand. Any reference to the 1984
Recommendations will be explicit. Any mappings relating to elements
which are in the 1992 version and not in the 1988 version will be noted
explicitly. X.400 defines an Interpersonal Messaging System (IPMS),
making use of a store and forward Message Transfer System. This document
relates to the IPMS, and not to wider application of X.400, such as EDI
as defined in X.435.},
URL="http://www.rfc-editor.org/rfc/rfc2156.txt"
}

@TECHREPORT{rfc2157,
AUTHOR="H. Alvestrand",
TITLE="Mapping between {X.400} and {RFC-822/MIME} Message Bodies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2157,
PAGES=49,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document defines how to map body parts of X.400 messages
into MIME entities and vice versa, including the handling of multipart
messages and forwarded messages.",
URL="http://www.rfc-editor.org/rfc/rfc2157.txt"
}

@TECHREPORT{rfc2158,
AUTHOR="H. Alvestrand",
TITLE="{X.400} Image Body Parts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2158,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document contains the body parts defined in RFC 1495 for
carrying image formats that were originally defined in MIME through an
X.400 system. It also documents the OIDs assigned to these data formats
as FTAM body parts, which allow the MIME types to be converted to FTAM
body parts; this will probably be more useful than the new body parts
defined here.",
URL="http://www.rfc-editor.org/rfc/rfc2158.txt"
}

@TECHREPORT{rfc2159,
AUTHOR="H. Alvestrand",
TITLE="A {MIME} Body Part for {FAX}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2159,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document contains the definitions, originally contained
in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate
it to its X.400 representation.",
URL="http://www.rfc-editor.org/rfc/rfc2159.txt"
}

@TECHREPORT{rfc2160,
AUTHOR="H. Alvestrand",
TITLE="Carrying {PostScript} in {X.400} and {MIME}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2160,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document describes methods for carrying PostScript
information in the two standard mail systems MIME and X.400, and the
conversion between them. It uses the notational conventions of RFC 2157,
and the conversion is further described in RFC 2156.",
URL="http://www.rfc-editor.org/rfc/rfc2160.txt"
}

@TECHREPORT{rfc2161,
AUTHOR="H. Alvestrand",
TITLE="A {MIME} Body Part for {ODA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2161,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document contains the definitions, originally contained
in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to
translate it to its X.400 representation.",
URL="http://www.rfc-editor.org/rfc/rfc2161.txt"
}

@TECHREPORT{rfc2162,
AUTHOR="C. Allocchio",
TITLE="{MaXIM-11} - Mapping between {X.400} / Internet mail and Mail-11 mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2162,
PAGES=34,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2162.txt"
}

@TECHREPORT{rfc2163,
AUTHOR="C. Allocchio",
TITLE="Using the Internet {DNS} to Distribute {MIXER} Conformant Global Address
Mapping {(MCGAM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2163,
PAGES=26,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2163.txt"
}

@TECHREPORT{rfc2164,
AUTHOR="S. E. Kille",
TITLE="Use of an {X.500/LDAP} directory to support {MIXER} address mapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2164,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This specification defines how to represent and maintain these
mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an
X.500 or LDAP directory.",
URL="http://www.rfc-editor.org/rfc/rfc2164.txt"
}

@TECHREPORT{rfc2199,
AUTHOR="A. Ramos",
TITLE="Request for Comments Summary {RFC} Numbers {2100-2199}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2199,
PAGES=23,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
2100 through RFCs 2199. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2199.txt"
}

@TECHREPORT{rfc2225,
AUTHOR="M. Laubach and J. Y. Halpern",
TITLE="Classical {IP} and {ARP} over {ATM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2225,
PAGES=28,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="This memo defines an initial application of classical IP and
ARP in an Asynchronous Transfer Mode (ATM) network environment
configured as a Logical IP Subnetwork (LIS).",
URL="http://www.rfc-editor.org/rfc/rfc2225.txt"
}

@TECHREPORT{rfc2247,
AUTHOR="S. E. Kille and M. Wahl and A. Grimstad and R. Huber and S. Sataluri",
TITLE="Using Domains in {LDAP/X.500} Distinguished Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2247,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document defines an algorithm by which a name registered
with the Internet Domain Name Service can be represented as an LDAP
distinguished name.",
URL="http://www.rfc-editor.org/rfc/rfc2247.txt"
}

@TECHREPORT{rfc2248,
AUTHOR="N. Freed and S. E. Kille",
TITLE="Network Services Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2248,
PAGES=19,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This MIB may be used on its own for any application, and for
most simple applications this will suffice. This MIB is also designed to
serve as a building block which can be used in conjunction with
application-specific monitoring and management.",
URL="http://www.rfc-editor.org/rfc/rfc2248.txt"
}

@TECHREPORT{rfc2249,
AUTHOR="N. Freed and S. E. Kille",
TITLE="Mail Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2249,
PAGES=28,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. Specifically, this memo extends the basic Network Services
Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It
may also be used to monitor MTA components within gateways.",
URL="http://www.rfc-editor.org/rfc/rfc2249.txt"
}

@TECHREPORT{rfc2250,
AUTHOR="D. Hoffman and G. Fernando and V. Goyal and M. Reha Civanlar",
TITLE="{RTP} Payload Format for {MPEG1/MPEG2} Video",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2250,
PAGES=16,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This memo describes a packetization scheme for MPEG video and
audio streams. The scheme proposed can be used to transport such a video
or audio flow over the transport protocols supported by RTP. Two
approaches are described. The first is designed to support maximum
interoperability with MPEG System environments. The second is designed
to provide maximum compatibility with other RTP-encapsulated media
streams and future conference control work of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2250.txt"
}

@TECHREPORT{rfc2257,
AUTHOR="M. Daniele and B. Wijnen and D. Francisco",
TITLE="Agent Extensibility {(AgentX)} Protocol Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2257,
PAGES=80,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2257.txt"
}

@TECHREPORT{rfc2258,
AUTHOR="J. Ordille",
TITLE="Internet Nomenclator Project",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2258,
PAGES=15,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2258.txt"
}

@TECHREPORT{rfc2259,
AUTHOR="J. Elliott and J. Ordille",
TITLE="Simple Nomenclator Query Protocol {(SNQP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2259,
PAGES=30,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="The Simple Nomenclator Query Protocol (SNQP) allows a client
to communicate with a descriptive name service or other relational-style
query service. The protocol is useful to services that search many data
repositories for query responses. SNQP is an ASCII protocol in the
request-reply style of SMTP. It was specifically designed for use with
the Nomenclator name and information service, and has been useful
elsewhere.",
URL="http://www.rfc-editor.org/rfc/rfc2259.txt"
}

@TECHREPORT{rfc2260,
AUTHOR="T. Bates and Y. Rekhter",
TITLE="Scalable Support for Multi-homed Multi-provider Connectivity",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2260,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document describes addressing and routing strategies for
multi-homed enterprises attached to multiple Internet Service Providers
(ISPs) that are intended to reduce the routing overhead due to these
enterprises in the global Internet routing system.",
URL="http://www.rfc-editor.org/rfc/rfc2260.txt"
}

@TECHREPORT{rfc2261,
AUTHOR="D. Harrington and R. Presuhn and B. Wijnen and Infonetics Research",
TITLE="An Architecture for Describing {SNMP} Management Frameworks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2261,
PAGES=56,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document describes an architecture for describing SNMP
Management Frameworks. The architecture is designed to be modular to
allow the evolution of the SNMP protocol standards over time. The major
portions of the architecture are an SNMP engine containing a Message
Processing Subsystem, a Security Subsystem and an Access Control
Subsystem, and possibly multiple SNMP applications which provide
specific functional processing of management data.",
URL="http://www.rfc-editor.org/rfc/rfc2261.txt"
}

@TECHREPORT{rfc2262,
AUTHOR="J. D. Case and D. Harrington and R. Presuhn and B. Wijnen and Infonetics
Research",
TITLE="Message Processing and Dispatching for the Simple Network Management
Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2262,
PAGES=39,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document describes the Message Processing and Dispatching
for SNMP messages within the SNMP architecture (RFC2261). It defines the
procedures for dispatching potentially multiple versions of SNMP
messages to the proper SNMP Message Processing Models, and for
dispatching PDUs to SNMP applications. This document also describes one
Message Processing Model - the SNMPv3 Message Processing Model.",
URL="http://www.rfc-editor.org/rfc/rfc2262.txt"
}

@TECHREPORT{rfc2263,
AUTHOR="D. Levi and P. Meyer and B. Stewart",
TITLE="{SNMPv3} Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2263,
PAGES=70,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="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. This memo
also defines MIB modules for specifying targets of management
operations, for notification filtering, and for proxy forwarding.",
URL="http://www.rfc-editor.org/rfc/rfc2263.txt"
}

@TECHREPORT{rfc2264,
AUTHOR="Uri Blumenthal and Infonetics Research and B. Wijnen",
TITLE="User-based Security Model {(USM)} for version 3 of the Simple Network
Management Protocol {(SNMPv3)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2264,
PAGES=76,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document describes the User-based Security Model (USM)
for SNMP version 3 for use in the SNMP architecture (RFC2261). It
defines the Elements of Procedure for providing SNMP message level
security. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this Security
Model.",
URL="http://www.rfc-editor.org/rfc/rfc2264.txt"
}

@TECHREPORT{rfc2265,
AUTHOR="B. Wijnen and Infonetics Research and R. Presuhn and K. McCloghrie",
TITLE="View-based Access Control Model {(VACM)} for the Simple Network Management
Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2265,
PAGES=36,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document describes the View-based Access Control Model
for use in the SNMP architecture (RFC2261). It defines the Elements of
Procedure for controlling access to management information. This
document also includes a MIB for remotely managing the configuration
parameters for the View-based Access Control Model.",
URL="http://www.rfc-editor.org/rfc/rfc2265.txt"
}

@TECHREPORT{rfc2266,
AUTHOR="J. Flick",
TITLE="Definitions of Managed Objects for {IEEE} {802.12} Repeater Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2266,
PAGES=56,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing network
repeaters based on IEEE 802.12.",
URL="http://www.rfc-editor.org/rfc/rfc2266.txt"
}

@TECHREPORT{rfc2267,
AUTHOR="P. Ferguson and D. Senie",
TITLE="Network Ingress Filtering: Defeating Denial of Service Attacks which employ
{IP} Source Address Spoofing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2267,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="Recent occurrences of various Denial of Service (DoS) attacks
which have employed forged source addresses have proven to be a
troublesome issue for Internet Service Providers and the Internet
community overall. This paper discusses a simple, effective, and
straightforward method for using ingress traffic filtering to prohibit
DoS attacks which use forged IP addresses to be propagated from 'behind'
an Internet Service Provider's (ISP) aggregation point.",
URL="http://www.rfc-editor.org/rfc/rfc2267.txt"
}

@TECHREPORT{rfc2268,
AUTHOR="R. Rivest",
TITLE="A Description of the {RC2(r)} Encryption Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2268,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This memo describes a conventional (secret-key) block
encryption algorithm, called RC2, which may be considered as a proposal
for a DES replacement. The input and output block sizes are 64 bits
each. The key size is variable, from one byte up to 128 bytes, although
the current implementation uses eight bytes. The algorithm is designed
to be easy to implement on 16-bit microprocessors. On an IBM AT, the
encryption runs about twice as fast as DES (assuming that key expansion
has been done).",
URL="http://www.rfc-editor.org/rfc/rfc2268.txt"
}

@TECHREPORT{rfc2269,
AUTHOR="G. Armitage",
TITLE="Using the {MARS} Model in {non-ATM} {NBMA} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2269,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2269.txt"
}

@TECHREPORT{rfc2270,
AUTHOR="J. Stewart and T. Bates and R. Chandra and E. H. Chen",
TITLE="Using a Dedicated {AS} for Sites Homed to a Single Provider",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2270,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2270.txt"
}

@TECHREPORT{rfc2276,
AUTHOR="K. Sollins",
TITLE="Architectural Principles of Uniform Resource Name Resolution",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2276,
PAGES=24,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document addresses the issues of the discovery of URN
(Uniform Resource Name) resolver services that in turn will directly
translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform
Resource Characteristics). The document falls into three major parts,
the assumptions underlying the work, the guidelines in order to be a
viable Resolver Discovery Service or RDS, and a framework for designing
RDSs. The guidelines fall into three principle areas: evolvability,
usability, and security and privacy. An RDS that is compliant with the
framework will not necessarily be compliant with the guidelines.
Compliance with the guidelines will need to be validated separately.",
URL="http://www.rfc-editor.org/rfc/rfc2276.txt"
}

@TECHREPORT{rfc2277,
AUTHOR="H. Alvestrand",
TITLE="{IETF} Policy on Character Sets and Languages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2277,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This document is the current policies being applied by the
Internet Engineering Steering Group (IESG) towards the standardization
efforts in the Internet Engineering Task Force (IETF) in order to help
Internet protocols fulfill these requirements.",
URL="http://www.rfc-editor.org/rfc/rfc2277.txt"
}

@TECHREPORT{rfc2278,
AUTHOR="N. Freed and J. B. Postel",
TITLE="{IANA} Charset Registration Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2278,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="MIME (RFC-2045, RFC-2046, RFC-2047, RFC-2184) and various
other modern Internet protocols are capable of using many different
charsets. This in turn means that the ability to label different
charsets is essential. This registration procedure exists solely to
associate a specific name or names with a given charset and to give an
indication of whether or not a given charset can be used in MIME text
objects. In particular, the general applicability and appropriateness of
a given registered charset is a protocol issue, not a registration
issue, and is not dealt with by this registration procedure.",
URL="http://www.rfc-editor.org/rfc/rfc2278.txt"
}

@TECHREPORT{rfc2279,
AUTHOR="F. Yergeau",
TITLE="{UTF-8,} a transformation format of {ISO} 10646",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2279,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2279.txt"
}

@TECHREPORT{rfc2280,
AUTHOR="C. Alaettinoglu and T. Bates and E. Gerich and D. Karrenberg and D. L.
Meyer and M. Terpstra and C. Villamizar",
TITLE="Routing Policy Specification Language {(RPSL)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2280,
PAGES=53,
DAYS=15,
MONTH=jan,
YEAR=1998,
ABSTRACT="This memo is the reference document for the Routing Policy
Specification Language (RPSL). RPSL allows a network operator to be able
to specify routing policies at various levels in the Internet hierarchy;
for example at the Autonomous System (AS) level. At the same time,
policies can be specified with sufficient detail in RPSL so that low
level router configurations can be generated from them. RPSL is
extensible; new routing protocols and new protocol features can be
introduced at any time.",
URL="http://www.rfc-editor.org/rfc/rfc2280.txt"
}

@TECHREPORT{rfc2281,
AUTHOR="T. Li and B. Cole and P. Morton and D. Li",
TITLE="Cisco Hot Standby Router Protocol {(HSRP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2281,
PAGES=17,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="The memo specifies the Hot Standby Router Protocol (HSRP). The
goal of the protocol is to allow hosts to appear to use a single router
and to maintain connectivity even if the actual first hop router they
are using fails. Multiple routers participate in this protocol and in
concert create the illusion of a single virtual router. The protocol
insures that one and only one of the routers is forwarding packets on
behalf of the virtual router. End hosts forward their packets to the
virtual router.",
URL="http://www.rfc-editor.org/rfc/rfc2281.txt"
}

@TECHREPORT{rfc2282,
AUTHOR="J. Galvin",
TITLE="{IAB} and {IESG} Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2282,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2282.txt"
}

@TECHREPORT{rfc2283,
AUTHOR="T. Bates and R. Chandra and D. Katz and Y. Rekhter",
TITLE="Multiprotocol Extensions for {BGP-4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2283,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="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't
support the extensions.",
URL="http://www.rfc-editor.org/rfc/rfc2283.txt"
}

@TECHREPORT{rfc2284,
AUTHOR="L. Blunk and J. Vollbrecht",
TITLE="{PPP} Extensible Authentication Protocol {(EAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2284,
PAGES=15,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document defines the PPP Extensible Authentication
Protocol (EAP). The Link Establishment and Authentication phases, and
the Authentication-Protocol Configuration Option, are defined in The
Point-to-Point Protocol (PPP).",
URL="http://www.rfc-editor.org/rfc/rfc2284.txt"
}

@TECHREPORT{rfc2285,
AUTHOR="R. Mandeville",
TITLE="Benchmarking Terminology for {LAN} Switching Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2285,
PAGES=25,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="This document is intended to provide terminology for the
benchmarking of local area network (LAN) switching devices. It extends
the terminology already defined for benchmarking network interconnect
devices in RFCs 1242 and 1944 to switching devices.",
URL="http://www.rfc-editor.org/rfc/rfc2285.txt"
}

@TECHREPORT{rfc2286,
AUTHOR="J. Kapp",
TITLE="Test Cases for {HMAC-RIPEMD160} and {HMAC-RIPEMD128}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2286,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2286.txt"
}

@TECHREPORT{rfc2287,
AUTHOR="C. Krupczak and J. Saperia",
TITLE="Definitions of {System-Level} Managed Objects for Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2287,
PAGES=44,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes a basic set of managed objects
for fault, configuration and performance management of applications from
a systems perspective. More specifically, the managed objects are
restricted to information that can be determined from the system itself
and which does not require special instrumentation within the
applications to make the information available.",
URL="http://www.rfc-editor.org/rfc/rfc2287.txt"
}

@TECHREPORT{rfc2288,
AUTHOR="C. A. Lynch and C. Preston and R. W. Daniel",
TITLE="Using Existing Bibliographic Identifiers as Uniform Resource Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2288,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="A system for Uniform Resource Names (URNs) must be capable of
supporting identifiers from existing widely-used naming systems. This
document discusses how three major bibliographic identifiers (the ISBN,
ISSN and SICI) can be supported within the URN framework and the
currently proposed syntax for URNs.",
URL="http://www.rfc-editor.org/rfc/rfc2288.txt"
}

@TECHREPORT{rfc2289,
AUTHOR="N. Haller and C. Metz and P. Nesser and M. Straw",
TITLE="A {One-Time} Password System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2289,
PAGES=25,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="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 work
by Haller and RFC 1760.",
URL="http://www.rfc-editor.org/rfc/rfc2289.txt"
}

@TECHREPORT{rfc2290,
AUTHOR="J. Solomon and S. Glass",
TITLE="{Mobile-IPv4} Configuration Option for {PPP} {IPCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2290,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="Mobile IP (RFC 2002) 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 (RFC 1661)
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) (RFC 1332). Using this option, two
peers can communicate their support for Mobile IP during the IPCP phase
of PPP. Familiarity with Mobile IP (RFC 2002), IPCP (RFC 1332), and PPP
(RFC 1661) is assumed.",
URL="http://www.rfc-editor.org/rfc/rfc2290.txt"
}

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

@TECHREPORT{rfc2292,
AUTHOR="W. Richard Stevens and M. Thomas",
TITLE="Advanced Sockets {API} for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2292,
PAGES=67,
DAYS=15,
MONTH=feb,
YEAR=1998,
ABSTRACT="Specifications are in progress for changes to the sockets API
to support IP version 6 (RFC-2133). 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.",
URL="http://www.rfc-editor.org/rfc/rfc2292.txt"
}

@TECHREPORT{rfc2293,
AUTHOR="S. E. Kille",
TITLE="Representing Tables and Subtrees in the {X.500} Directory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2293,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document defines techniques for representing two types of
information mapping in the OSI Directory.",
URL="http://www.rfc-editor.org/rfc/rfc2293.txt"
}

@TECHREPORT{rfc2294,
AUTHOR="S. E. Kille",
TITLE="Representing the {O/R} Address hierarchy in the {X.500} Directory
Information Tree",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2294,
PAGES=13,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document defines a representation of the O/R Address
hierarchy in wthe Directory Information Tree. This is useful for a range
of purposes, including support for MHS Routing and support for X.400/RFC
822 address mappings.",
URL="http://www.rfc-editor.org/rfc/rfc2294.txt"
}

@TECHREPORT{rfc2295,
AUTHOR="K. Holtman and A. Mutz",
TITLE="Transparent Content Negotiation in {HTTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2295,
PAGES=58,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2295.txt"
}

@TECHREPORT{rfc2296,
AUTHOR="K. Holtman and A. Mutz",
TITLE="{HTTP} Remote Variant Selection Algorithm {--} {RVSA/1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2296,
PAGES=13,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2296.txt"
}

@TECHREPORT{rfc2297,
AUTHOR="P. Newman and W. L. Edwards and R. Hinden and E. Hoffman and FongChing Liaw
and T. Lyon and G. Minshall",
TITLE="Ipsilon's General Switch Management Protocol Specification Version {2.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2297,
PAGES=109,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This memo specifies enhancements to the General Switch
Management Protocol (GSMP) (RFC1987). 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.",
URL="http://www.rfc-editor.org/rfc/rfc2297.txt"
}

@TECHREPORT{rfc2298,
AUTHOR="R. Fajman",
TITLE="An Extensible Message Format for Message Disposition Notifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2298,
PAGES=28,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT={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 {"}LAN-based{"} systems, and often referred to as {"}read
receipts,{"} {"}acknowledgements,{"} or {"}receipt notifications.{"} 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.},
URL="http://www.rfc-editor.org/rfc/rfc2298.txt"
}

@TECHREPORT{rfc2300,
AUTHOR="J. B. Postel and J. F. Reynolds",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2300,
PAGES=59,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2300.txt"
}

@TECHREPORT{rfc2301,
AUTHOR="L. McIntyre and S. Zilles and R. Buckley and D. Venable and G. Parsons and
J. Rafferty",
TITLE="File Format for Internet Fax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2301,
PAGES=77,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2301.txt"
}

@TECHREPORT{rfc2302,
AUTHOR="G. Parsons and J. Rafferty and S. Zilles",
TITLE="Tag Image File Format {(TIFF)} - image/tiff {MIME} Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2302,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document describes the registration of the MIME sub-type
image/tiff. The baseline encoding is defined by TIFF.",
URL="http://www.rfc-editor.org/rfc/rfc2302.txt"
}

@TECHREPORT{rfc2303,
AUTHOR="C. Allocchio",
TITLE="Minimal {PSTN} address format in Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2303,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This memo describes the MINIMAL addressing method to encode
PSTN addresses into e-mail addresses and the standard extension
mechanism to allow definition of further standard elements. The opposite
problem, i.e. to allow a traditional numeric-only PSTN device user to
access the e-mail transport service, is not discussed here.",
URL="http://www.rfc-editor.org/rfc/rfc2303.txt"
}

@TECHREPORT{rfc2304,
AUTHOR="C. Allocchio",
TITLE="Minimal {FAX} address format in Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2304,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This memo describes the MINIMAL addressing method and standard
extensions to encode FAX addresses in e-mail addresses, as required in
reference RFC 2303. The opposite problem, i.e. to allow a traditional
numeric-only fax device user to access the e-mail transport service, is
not discussed here.",
URL="http://www.rfc-editor.org/rfc/rfc2304.txt"
}

@TECHREPORT{rfc2305,
AUTHOR="K. Toyoda and H. Ohno and J. Murai and D. Wing",
TITLE="A Simple Mode of Facsimile Using Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2305,
PAGES=13,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT={This specification provides for {"}simple mode{"} carriage of
facsimile data over the Internet. 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.},
URL="http://www.rfc-editor.org/rfc/rfc2305.txt"
}

@TECHREPORT{rfc2306,
AUTHOR="G. Parsons and J. Rafferty",
TITLE="Tag Image File Format {(TIFF)} - F Profile for Facsimile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2306,
PAGES=25,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document describes in detail the definition of TIFF-F
that is used to store facsimile images. The TIFF-F encoding has been
folklore with no standard reference definition before this document.",
URL="http://www.rfc-editor.org/rfc/rfc2306.txt"
}

@TECHREPORT{rfc2307,
AUTHOR="L. Howard",
TITLE="An Approach for Using {LDAP} as a Network Information Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2307,
PAGES=21,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document describes an experimental mechanism for mapping
entities related to TCP/IP and the UNIX system into X.500 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.",
URL="http://www.rfc-editor.org/rfc/rfc2307.txt"
}

@TECHREPORT{rfc2308,
AUTHOR="M. C. Andrews",
TITLE="Negative Caching of {DNS} Queries {(DNS} {NCACHE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2308,
PAGES=19,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2308.txt"
}

@TECHREPORT{rfc2309,
AUTHOR="B. Braden and D. D. Clark and Jon Crowcroft and B. S. Davie and S. E.
Deering and D. Estrin and S. Floyd and V. Jacobson",
TITLE="Recommendations on Queue Management and Congestion Avoidance in the
Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2309,
PAGES=17,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2309.txt"
}

@TECHREPORT{rfc2310,
AUTHOR="K. Holtman",
TITLE="The Safe Response Header Field",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2310,
PAGES=5,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2310.txt"
}

@TECHREPORT{rfc2311,
AUTHOR="S. Dusse and P. Hoffman and B. Ramsdell and L. Lundblade and L. Repka",
TITLE="{S/MIME} Version 2 Message Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2311,
PAGES=37,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="S/MIME (Secure/Multipurpose Internet Mail Extensions) provides
a consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).",
URL="http://www.rfc-editor.org/rfc/rfc2311.txt"
}

@TECHREPORT{rfc2312,
AUTHOR="S. Dusse and P. Hoffman and B. Ramsdell and J. Weinstein",
TITLE="{S/MIME} Version 2 Certificate Handling",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2312,
PAGES=20,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="S/MIME (Secure/Multipurpose Internet Mail Extensions),
described in RFC 2311, provides a method to send and receive secure MIME
messages. In order to validate the keys of a message sent to it, an
S/MIME agent needs to certify that the key is valid. This memo describes
the mechanisms S/MIME uses to create and validate keys using
certificates.",
URL="http://www.rfc-editor.org/rfc/rfc2312.txt"
}

@TECHREPORT{rfc2313,
AUTHOR="B. Kaliski",
TITLE="{PKCS} {#1:} {RSA} Encryption Version {1.5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2313,
PAGES=19,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document describes a method for encrypting data using the
RSA public-key cryptosystem.",
URL="http://www.rfc-editor.org/rfc/rfc2313.txt"
}

@TECHREPORT{rfc2314,
AUTHOR="B. Kaliski",
TITLE="{PKCS} {#10:} Certification Request Syntax Version {1.5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2314,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document describes a syntax for certification requests.",
URL="http://www.rfc-editor.org/rfc/rfc2314.txt"
}

@TECHREPORT{rfc2315,
AUTHOR="B. Kaliski",
TITLE="{PKCS} {#7:} Cryptographic Message Syntax Version {1.5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2315,
PAGES=32,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document describes a general syntax for data that may
have cryptography applied to it, such as digital signatures and digital
envelopes. The syntax admits recursion, so that, for example, one
envelope can be nested inside another, or one party can sign some
previously enveloped digital data. It also allows arbitrary attributes,
such as signing time, to be authenticated along with the content of a
message, and provides for other attributes such as countersignatures to
be associated with a signature. A degenerate case of the syntax provides
a means for disseminating certificates and certificate-revocation lists.",
URL="http://www.rfc-editor.org/rfc/rfc2315.txt"
}

@TECHREPORT{rfc2316,
AUTHOR="S. M. Bellovin",
TITLE="Report of the {IAB} Security Architecture Workshop",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2316,
PAGES=9,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="On 3-5 March 1997, the IAB held a security architecture
workshop at Bell Labs in Murray Hill, NJ. We identified the core
security components of the architecture, and specified several documents
that need to be written. Most importantly, we agreed that security was
not optional, and that it needed to be designed in from the beginning.",
URL="http://www.rfc-editor.org/rfc/rfc2316.txt"
}

@TECHREPORT{rfc2317,
AUTHOR="H. Eidnes and G. de Groot and P. Vixie",
TITLE="Classless {IN-ADDR.ARPA} delegation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2317,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="This document describes a way to do IN-ADDR.ARPA delegation on
non-octet boundaries for address spaces covering fewer than 256
addresses. The proposed method should thus remove one of the objections
to subnet on non-octet boundaries but perhaps more significantly, make
it possible to assign IP address space in smaller chunks than 24-bit
prefixes, without losing the ability to delegate authority for the
corresponding IN-ADDR.ARPA mappings. The proposed method is fully
compatible with the original DNS lookup mechanisms specified in RFC
1034, i.e. there is no need to modify the lookup algorithm used, and
there should be no need to modify any software which does DNS lookups.",
URL="http://www.rfc-editor.org/rfc/rfc2317.txt"
}

@TECHREPORT{rfc2318,
AUTHOR="H. Lie and B. Bos and C. Lilley",
TITLE="The text/css Media Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2318,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2318.txt"
}

@TECHREPORT{rfc2319,
AUTHOR="Koi8-u Working Group",
TITLE="Ukrainian Character Set {KOI8-U}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2319,
PAGES=9,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2319.txt"
}

@TECHREPORT{rfc2320,
AUTHOR="M. Greene and J. Luciani and K. White and T. Kuo",
TITLE="Definitions of Managed Objects for Classical {IP} and {ARP} Over {ATM}
Using {SMIv2} {(IPOA-MIB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2320,
PAGES=52,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2320.txt"
}

@TECHREPORT{rfc2321,
AUTHOR="A. Bressen",
TITLE="{RITA} {--} The Reliable Internetwork Troubleshooting Agent",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2321,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="A Description of the usage of Nondeterministic Troubleshooting
and Diagnostic Methodologies as applied to today's complex
nondeterministic networks and environments.",
URL="http://www.rfc-editor.org/rfc/rfc2321.txt"
}

@TECHREPORT{rfc2322,
AUTHOR="  and A. Koopal and R. van Mook",
TITLE="Management of {IP} numbers by peg-dhcp",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2322,
PAGES=7,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2322.txt"
}

@TECHREPORT{rfc2323,
AUTHOR="A. Ramos",
TITLE="{IETF} Identification and Security Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2323,
PAGES=5,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT={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{"}.},
URL="http://www.rfc-editor.org/rfc/rfc2323.txt"
}

@TECHREPORT{rfc2324,
AUTHOR="L. Masinter",
TITLE="Hyper Text Coffee Pot Control Protocol {(HTCPCP/1.0)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2324,
PAGES=10,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="This document describes HTCPCP, a protocol for controlling,
monitoring, and diagnosing coffee pots.",
URL="http://www.rfc-editor.org/rfc/rfc2324.txt"
}

@TECHREPORT{rfc2325,
AUTHOR="M. Slavitch",
TITLE="Definitions of Managed Objects for {Drip-Type} Heated Beverage Hardware
Devices using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2325,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="This memo defines an extension to the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for the management of
coffee-brewing and maintenance devices.",
URL="http://www.rfc-editor.org/rfc/rfc2325.txt"
}

@TECHREPORT{rfc2326,
AUTHOR="Henning Schulzrinne and Asha Rao and R. Lanphier",
TITLE="Real Time Streaming Protocol {(RTSP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2326,
PAGES=92,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2326.txt"
}

@TECHREPORT{rfc2327,
AUTHOR="M. Handley and V. Jacobson",
TITLE="{SDP:} Session Description Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2327,
PAGES=42,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2327.txt"
}

@TECHREPORT{rfc2328,
AUTHOR="J. Moy",
TITLE="{OSPF} Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2328,
PAGES=244,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2328.txt"
}

@TECHREPORT{rfc2329,
AUTHOR="J. Moy",
TITLE="{OSPF} Standardization Report",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2329,
PAGES=9,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="This memo documents how the requirements for advancing a
routing protocol to Full Standard have been met for OSPFv2.",
URL="http://www.rfc-editor.org/rfc/rfc2329.txt"
}

@TECHREPORT{rfc2330,
AUTHOR="V. Paxson and G. T. Almes and J. Mahdavi and M. Mathis",
TITLE="Framework for {IP} Performance Metrics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2330,
PAGES=40,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="The purpose of this memo is to define a general framework for
particular metrics to be developed by the IETF's IP Performance Metrics
effort, begun by the Benchmarking Methodology Working Group (BMWG) of
the Operational Requirements Area, and being continued by the IP
Performance Metrics Working Group (IPPM) of the Transport Area.",
URL="http://www.rfc-editor.org/rfc/rfc2330.txt"
}

@TECHREPORT{rfc2331,
AUTHOR="M. P. Maher",
TITLE="{ATM} Signalling Support for {IP} over {ATM} - {UNI} Signalling {4.0}
Update",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2331,
PAGES=26,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="This memo describes how to efficiently use the ATM call
control signalling procedures defined in UNI Signalling 4.0 to support
IP over ATM environments as described in RFC 2225 and in RFC 2332.",
URL="http://www.rfc-editor.org/rfc/rfc2331.txt"
}

@TECHREPORT{rfc2332,
AUTHOR="J. Luciani and D. Katz and D. Piscitello and B. Cole and N. Doraswamy",
TITLE="{NBMA} Next Hop Resolution Protocol {(NHRP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2332,
PAGES=52,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2332.txt"
}

@TECHREPORT{rfc2333,
AUTHOR="D. Cansever",
TITLE="{NHRP} Protocol Applicability Statement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2333,
PAGES=9,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2333.txt"
}

@TECHREPORT{rfc2334,
AUTHOR="J. Luciani and G. Armitage and J. Y. Halpern and N. Doraswamy",
TITLE="Server Cache Synchronization Protocol {(SCSP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2334,
PAGES=40,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2334.txt"
}

@TECHREPORT{rfc2335,
AUTHOR="J. Luciani",
TITLE="A Distributed {NHRP} Service Using {SCSP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2335,
PAGES=7,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="This document describes a method for distributing an NHRP
service within a LIS. This method uses the Server Cache Synchronization
Protocol (SCSP) to synchronize the client information databases held by
NHRP Servers (NHSs) within a LIS.",
URL="http://www.rfc-editor.org/rfc/rfc2335.txt"
}

@TECHREPORT{rfc2336,
AUTHOR="J. Luciani",
TITLE="Classical {IP} to {NHRP} Transition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2336,
PAGES=5,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="This document describes methods and procedures for the
graceful transition from an ATMARP LIS to an NHRP LIS network model over
ATM.",
URL="http://www.rfc-editor.org/rfc/rfc2336.txt"
}

@TECHREPORT{rfc2337,
AUTHOR="D. Farinacci and D. L. Meyer and Y. Rekhter",
TITLE="{Intra-LIS} {IP} multicast among routers over {ATM} using Sparse Mode {PIM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2337,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2337.txt"
}

@TECHREPORT{rfc2338,
AUTHOR="S. Knight and D. Weaver and D. Whipple and R. Hinden and D. Mitzel and P.
J. Hunt and P. Higginson and M. Shand",
TITLE="Virtual Router Redundancy Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2338,
PAGES=27,
DAYS=15,
MONTH=apr,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2338.txt"
}

@TECHREPORT{rfc2339,
AUTHOR="  and  {Sun Microsystems}",
TITLE="An Agreement Between the Internet Society, the {IETF,} and Sun
Microsystems, Inc",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2339,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2339.txt"
}

@TECHREPORT{rfc2340,
AUTHOR="B. Jamoussi and D. Jamieson and D. Williston and S. Gabe",
TITLE="Nortel's Virtual Network Switching {(VNS)} Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2340,
PAGES=14,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2340.txt"
}

@TECHREPORT{rfc2341,
AUTHOR="A. Valencia and M. Littlewood and T. Kolar",
TITLE={Cisco Layer Two Forwarding (Protocol) {{"}L2F{"}}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2341,
PAGES=29,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="This document describes the Layer Two Forwarding protocol
(L2F) which permits the tunneling of the link layer (i.e., HDLC, async
HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it
is possible to divorce the location of the initial dial-up server from
the location at which the dial-up protocol connection is terminated and
access to the network provided.",
URL="http://www.rfc-editor.org/rfc/rfc2341.txt"
}

@TECHREPORT{rfc2342,
AUTHOR="M. Gahrns and C. Newman",
TITLE="{IMAP4} Namespace",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2342,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="This document defines a NAMESPACE command that allows a client
to discover the prefixes of namespaces used by a server for personal
mailboxes, other users' mailboxes, and shared mailboxes. This allows a
client to avoid much of the manual user configuration that is now
necessary when mixing and matching IMAP4 clients and servers.",
URL="http://www.rfc-editor.org/rfc/rfc2342.txt"
}

@TECHREPORT{rfc2343,
AUTHOR="M. Reha Civanlar and G. Cash and B. G. Haskell",
TITLE="{RTP} Payload Format for Bundled {MPEG}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2343,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2343.txt"
}

@TECHREPORT{rfc2344,
EDITOR="Gabriel E. Montenegro",
TITLE="Reverse Tunneling for Mobile {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2344,
PAGES=19,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2344.txt"
}

@TECHREPORT{rfc2345,
AUTHOR="J. Klensin and T. Wolf and G. Oglesby",
TITLE="Domain Names and Company Name Retrieval",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2345,
PAGES=14,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2345.txt"
}

@TECHREPORT{rfc2346,
AUTHOR="J. Palme",
TITLE="Making Postscript and {PDF} International",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2346,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2346.txt"
}

@TECHREPORT{rfc2347,
AUTHOR="G. Malkin and A. Harkin",
TITLE="{TFTP} Option Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2347,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="The Trivial File Transfer Protocol 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.",
URL="http://www.rfc-editor.org/rfc/rfc2347.txt"
}

@TECHREPORT{rfc2348,
AUTHOR="G. Malkin and A. Harkin",
TITLE="{TFTP} Blocksize Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2348,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="This document describes a TFTP option which allows the client
and server to negotiate a blocksize more applicable to the network
medium.",
URL="http://www.rfc-editor.org/rfc/rfc2348.txt"
}

@TECHREPORT{rfc2349,
AUTHOR="G. Malkin and A. Harkin",
TITLE="{TFTP} Timeout Interval and Transfer Size Options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2349,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2349.txt"
}

@TECHREPORT{rfc2350,
AUTHOR="Nevil Brownlee and E. Guttman",
TITLE="Expectations for Computer Security Incident Response",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2350,
PAGES=38,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT="The purpose of this document is to express the general
Internet community's expectations of Computer Security Incident Response
Teams (CSIRTs). It is not possible to define a set of requirements that
would be appropriate for all teams, but it is possible and helpful to
list and describe the general set of topics and issues which are of
concern and interest to constituent communities. CSIRT constituents have
a legitimate need and right to fully understand the policies and
procedures of 'their' Computer Security Incident Response Team. One way
to support this understanding is to supply detailed information which
users may consider, in the form of a formal template completed by the
CSIRT. An outline of such a template and a filled in example are
provided. This document is a product of the Guidelines and
Recommendations for Security Incident Processing Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2350.txt"
}

@TECHREPORT{rfc2351,
AUTHOR="A. Robert",
TITLE="Mapping of Airline Reservation, Ticketing, and Messaging Traffic over {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2351,
PAGES=23,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="This memo specifies a protocol for the encapsulation of the
airline specific protocol over IP.",
URL="http://www.rfc-editor.org/rfc/rfc2351.txt"
}

@TECHREPORT{rfc2352,
AUTHOR="O. Vaughan",
TITLE="A Convention For Using Legal Names as Domain Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2352,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="The purpose of this memo is to focus discussion on the
particular problems with the exhaustion of the top level domain space in
the Internet and the possible conflicts that can occur when multiple
organisations are vying for the same name. The proposed solutions in
this document are intended as a framework for development, such that a
general consensus will emerge as to the appropriate solution to the
problems in each case, leading eventually to the adoption of standards.",
URL="http://www.rfc-editor.org/rfc/rfc2352.txt"
}

@TECHREPORT{rfc2353,
AUTHOR="G. Dudley",
TITLE="{APPN/HPR} in {IP} Networks {APPN} Implementers' Workshop Closed Pages
Document",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2353,
PAGES=48,
DAYS=15,
MONTH=may,
YEAR=1998,
ABSTRACT="This memo defines a method with which HPR nodes can use IP
networks for communication, and the enhancements to APPN required by
this method. This memo also describes an option set that allows the use
of the APPN connection network model to allow HPR nodes to use IP
networks for communication without having to predefine link connections.",
URL="http://www.rfc-editor.org/rfc/rfc2353.txt"
}

@TECHREPORT{rfc2354,
AUTHOR="C. E. Perkins and O. Hodson",
TITLE="Options for Repair of Streaming Media",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2354,
PAGES=12,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT="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. This document is the product of the Audio/Video Transport
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2354.txt"
}

@TECHREPORT{rfc2355,
AUTHOR="B. Kelly",
TITLE="{TN3270} Enhancements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2355,
PAGES=38,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT={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 {"}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. This protocol is negotiated under the TN3270E
Telnet Option, and is unrelated to the Telnet 3270 Regime Option as
defined in RFC 1041. This document is the product of the Telnet TN3270
Enhancements Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2355.txt"
}

@TECHREPORT{rfc2356,
AUTHOR="Gabriel E. Montenegro and V. P. Gupta",
TITLE="Sun's {SKIP} Firewall Traversal for Mobile {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2356,
PAGES=24,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT="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. 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. This document is the product of the IP
Routing for Wireless/Mobile Hosts Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2356.txt"
}

@TECHREPORT{rfc2357,
AUTHOR="Allison Mankin and A. Romanow and S. Bradner and V. Paxson",
TITLE="{IETF} Criteria for Evaluating Reliable Multicast Transport and Application
Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2357,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT="This memo describes the procedures and criteria for reviewing
reliable multicast protocols within the Transport Area (TSV) of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2357.txt"
}

@TECHREPORT{rfc2358,
AUTHOR="J. Flick and J. D. Johnson",
TITLE="Definitions of Managed Objects for the Ethernet-like Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2358,
PAGES=39,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT={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 {"}Definitions of Managed Objects
for the Ethernet-like Interface Types using SMIv2{"}. This memo extends
that specification by including management information useful for the
management of 100 Mb/s Ethernet interfaces.},
URL="http://www.rfc-editor.org/rfc/rfc2358.txt"
}

@TECHREPORT{rfc2359,
AUTHOR="J. Myers",
TITLE="{IMAP4} {UIDPLUS} extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2359,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT="The UIDPLUS extension of the Internet Message Access Protocol
(IMAP4) provides a set of features intended to reduce the amount of time
and resources used by some client operations. The features in UIDPLUS
are primarily intended for disconnected-use clients.",
URL="http://www.rfc-editor.org/rfc/rfc2359.txt"
}

@TECHREPORT{rfc2360,
AUTHOR="G. Scott",
TITLE="Guide for Internet Standards Writers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2360,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT={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, {"}Instructions to RFC Authors{"}.},
URL="http://www.rfc-editor.org/rfc/rfc2360.txt"
}

@TECHREPORT{rfc2361,
AUTHOR="E. Fleischman",
TITLE="{WAVE} and {AVI} Codec Registries",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2361,
PAGES=71,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT={Internet applications may reference specific codecs within the
WAVE and AVI registries as follows: video/vnd.avi; codec=XXX identifies
a specific video codec (i.e., XXX) within the AVI Registry;
audio/vnd.wave; codec=YYY identifies a specific audio codec (i.e., YYY)
within the WAVE Registry. Appendix A and Appendix B provides an
authoritative reference for the interpretation of the required {"}codec{"}
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.},
URL="http://www.rfc-editor.org/rfc/rfc2361.txt"
}

@TECHREPORT{rfc2362,
AUTHOR="D. Estrin and D. Farinacci and A. Helmy and D. Thaler and S. E. Deering and
M. Handley and V. Jacobson and C. Liu",
TITLE="Protocol Independent {Multicast-Sparse} Mode {(PIM-SM):} Protocol
Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2362,
PAGES=66,
DAYS=15,
MONTH=jun,
YEAR=1998,
ABSTRACT="This document describes a protocol for efficiently routing to
multicast groups that may span wide-area (and inter-domain) internets.
We refer to the approach as Protocol Independent Multicast--Sparse Mode
(PIM-SM) because it is not dependent on any particular unicast routing
protocol, and because it is designed to support sparse groups.",
URL="http://www.rfc-editor.org/rfc/rfc2362.txt"
}

@TECHREPORT{rfc2363,
AUTHOR="G. Gross and M. Kaycee and A. Li and A. Malis and J. Stephens",
TITLE="{PPP} Over {FUNI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2363,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="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 ATM Frame User Network Interface
(FUNI) for framing PPP encapsulated packets.",
URL="http://www.rfc-editor.org/rfc/rfc2363.txt"
}

@TECHREPORT{rfc2364,
AUTHOR="G. Gross and M. Kaycee and A. Li and A. Malis and J. Stephens",
TITLE="{PPP} Over {AAL5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2364,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="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 ATM Adaptation Layer 5 (AAL5) for
framing PPP encapsulated packets.",
URL="http://www.rfc-editor.org/rfc/rfc2364.txt"
}

@TECHREPORT{rfc2365,
AUTHOR="D. L. Meyer",
TITLE="Administratively Scoped {IP} Multicast",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2365,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT={This document defines the {"}administratively scoped IPv4
multicast space{"} to be the range 239.0.0.0 to 239.255.255.255. In
addition, it describes a simple set of semantics for the implementation
of Administratively Scoped IP Multicast. Finally, it provides a mapping
between the IPv6 multicast address classes (RFC1884) and IPv4 multicast
address classes.},
URL="http://www.rfc-editor.org/rfc/rfc2365.txt"
}

@TECHREPORT{rfc2366,
AUTHOR="C. d.  Chung and M. Greene",
TITLE="Definitions of Managed Objects for Multicast over {UNI} {3.0/3.1} based
{ATM} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2366,
PAGES=76,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects for IP hosts and
routers that use a Multicast Address Resolution Server (MARS) to support
IP multicast over ATM, as described in 'Support for Multicast over UNI
3.0/3.1 based ATM Networks'.",
URL="http://www.rfc-editor.org/rfc/rfc2366.txt"
}

@TECHREPORT{rfc2367,
AUTHOR="D. McDonald and C. Metz and B. Phan",
TITLE="{PF\\_KEY} Key Management {API,} Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2367,
PAGES=68,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="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'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).",
URL="http://www.rfc-editor.org/rfc/rfc2367.txt"
}

@TECHREPORT{rfc2368,
AUTHOR="P. Hoffman and L. Masinter and J. Zawinski",
TITLE="The mailto {URL} scheme",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2368,
PAGES=10,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="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, 'Uniform Resource Locators', and RFC
1808, 'Relative Uniform Resource Locators'. The syntax of 'mailto' 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.",
URL="http://www.rfc-editor.org/rfc/rfc2368.txt"
}

@TECHREPORT{rfc2369,
AUTHOR="G. W. Neufeld and J. Baer",
TITLE="The Use of {URLs} as {Meta-Syntax} for Core Mail List Commands and their
Transport through Message Header Fields",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2369,
PAGES=15,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="This is a proposal for additional header fields to be added to
email messages sent by email distribution lists. The content of each new
field is typically a URL - usually mailto (RFC2368) - which locates the
relevant information or performs the command directly. MTAs generating
the header fields SHOULD usually include a mailto based command, in
addition to any other protocols used, in order to support users who do
not have access to non-mail-based protocols.",
URL="http://www.rfc-editor.org/rfc/rfc2369.txt"
}

@TECHREPORT{rfc2370,
AUTHOR="R. Coltun",
TITLE="The {OSPF} Opaque {LSA} Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2370,
PAGES=15,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="This memo defines enhancements to the OSPF protocol to support
a new class of link-state advertisements (LSA) called Opaque LSAs.
Opaque LSAs provide a generalized mechanism to allow for the future
extensibility of OSPF. Opaque LSAs consist of a standard LSA header
followed by application-specific information. The information field may
be used directly by OSPF or by other applications. Standard OSPF
link-state database flooding mechanisms are used to distribute Opaque
LSAs to all or some limited portion of the OSPF topology.",
URL="http://www.rfc-editor.org/rfc/rfc2370.txt"
}

@TECHREPORT{rfc2371,
AUTHOR="J. Lyon and K. Evans and J. Klein",
TITLE="Transaction Internet Protocol Version {3.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2371,
PAGES=31,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2371.txt"
}

@TECHREPORT{rfc2372,
AUTHOR="K. Evans and J. Klein and J. Lyon",
TITLE="Transaction Internet Protocol - Requirements and Supplemental Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2372,
PAGES=24,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2372.txt"
}

@TECHREPORT{rfc2373,
AUTHOR="R. Hinden and S. E. Deering",
TITLE="{IP} Version 6 Addressing Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2373,
PAGES=26,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="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's required addresses.",
URL="http://www.rfc-editor.org/rfc/rfc2373.txt"
}

@TECHREPORT{rfc2374,
AUTHOR="R. Hinden and M. O'Dell and S. E. Deering",
TITLE="An {IPv6} Aggregatable Global Unicast Address Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2374,
PAGES=12,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT={This document defines an IPv6 aggregatable global unicast
address format for use in the Internet. The address format defined in
this document is consistent with the IPv6 Protocol and the {"}IPv6
Addressing Architecture{"}. It is designed to facilitate scalable Internet
routing.},
URL="http://www.rfc-editor.org/rfc/rfc2374.txt"
}

@TECHREPORT{rfc2375,
AUTHOR="R. Hinden and S. E. Deering",
TITLE="{IPv6} Multicast Address Assignments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2375,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT={This document defines the initial assignment of IPv6 multicast
addresses. It is based on the {"}IP Version 6 Addressing Architecture{"}
and
current IPv4 multicast address assignment found in
<ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>. It
adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4
assignments that were not relevant were not converted into IPv6
assignments.},
URL="http://www.rfc-editor.org/rfc/rfc2375.txt"
}

@TECHREPORT{rfc2376,
AUTHOR="E. Whitehead and M. Murata",
TITLE="{XML} Media Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2376,
PAGES=15,
DAYS=15,
MONTH=jul,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2376.txt"
}

@TECHREPORT{rfc2377,
AUTHOR="A. Grimstad and R. Huber and S. Sataluri and M. Wahl",
TITLE="Naming Plan for Internet {Directory-Enabled} Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2377,
PAGES=18,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2377.txt"
}

@TECHREPORT{rfc2378,
AUTHOR="R. Hedberg and P. Pomes",
TITLE="The {CCSO} Nameserver (Ph) Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2378,
PAGES=22,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2378.txt"
}

@TECHREPORT{rfc2379,
AUTHOR="L. Berger",
TITLE="{RSVP} over {ATM} Implementation Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2379,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="This memo presents specific implementation guidelines for
running RSVP over ATM switched virtual circuits (SVCs).",
URL="http://www.rfc-editor.org/rfc/rfc2379.txt"
}

@TECHREPORT{rfc2380,
AUTHOR="L. Berger",
TITLE="{RSVP} over {ATM} Implementation Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2380,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2380.txt"
}

@TECHREPORT{rfc2381,
AUTHOR="M. Garrett and M. Borden",
TITLE="Interoperation of {Controlled-Load} Service and Guaranteed Service with
{ATM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2381,
PAGES=43,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2381.txt"
}

@TECHREPORT{rfc2382,
EDITOR="E. Crawley and L. Berger and S. Berson",
TITLE="A Framework for Integrated Services and {RSVP} over {ATM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2382,
PAGES=30,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2382.txt"
}

@TECHREPORT{rfc2383,
AUTHOR="M. Suzuki",
TITLE="{ST2+} over {ATM} Protocol Specification - {UNI} {3.1} Version",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2383,
PAGES=50,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2383.txt"
}

@TECHREPORT{rfc2384,
AUTHOR="R. Gellens",
TITLE="{POP} {URL} Scheme",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2384,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="This memo defines a URL scheme for referencing a POP mailbox.",
URL="http://www.rfc-editor.org/rfc/rfc2384.txt"
}

@TECHREPORT{rfc2385,
AUTHOR="A. Heffernan",
TITLE="Protection of {BGP} Sessions via the {TCP} {MD5} Signature Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2385,
PAGES=6,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="This memo describes a TCP extension to enhance security for
BGP. It defines a new TCP option for carrying an MD5 (RFC1321) digest in
a TCP segment. This digest acts like a signature for that segment,
incorporating information known only to the connection end points. Since
BGP uses TCP as its transport, using this option in the way described in
this paper significantly reduces the danger from certain security
attacks on BGP.",
URL="http://www.rfc-editor.org/rfc/rfc2385.txt"
}

@TECHREPORT{rfc2386,
AUTHOR="E. Crawley and R. Nair and B. Rajagopalan and H. Sandick",
TITLE="A Framework for {QoS-based} Routing in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2386,
PAGES=37,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2386.txt"
}

@TECHREPORT{rfc2387,
AUTHOR="E. Levinson",
TITLE="The {MIME} {Multipart/Related} Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2387,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2387.txt"
}

@TECHREPORT{rfc2388,
AUTHOR="L. Masinter",
TITLE="Returning Values from Forms: multipart/form-data",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2388,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="This specification defines an Internet Media Type,
multipart/form-data, which can be used by a wide variety of applications
and transported by a wide variety of protocols as a way of returning a
set of values as the result of a user filling out a form.",
URL="http://www.rfc-editor.org/rfc/rfc2388.txt"
}

@TECHREPORT{rfc2389,
AUTHOR="P. Hethmon and R. Elz",
TITLE="Feature negotiation mechanism for the File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2389,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2389.txt"
}

@TECHREPORT{rfc2390,
AUTHOR="T. T. Bradley and C. M. Brown and A. Malis",
TITLE="Inverse Address Resolution Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2390,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2390.txt"
}

@TECHREPORT{rfc2391,
AUTHOR="P. Srisuresh and D. Gan",
TITLE="Load Sharing using {IP} Network Address Translation {(LSNAT)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2391,
PAGES=18,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2391.txt"
}

@TECHREPORT{rfc2392,
AUTHOR="E. Levinson",
TITLE="{Content-ID} and {Message-ID} Uniform Resource Locators",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2392,
PAGES=6,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT={The Uniform Resource Locator (URL) schemes, {"}cid:{"} and {"}mid:{"}
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.},
URL="http://www.rfc-editor.org/rfc/rfc2392.txt"
}

@TECHREPORT{rfc2393,
AUTHOR="A. Shacham and R. Monsour and R. Pereira and M. Thomas",
TITLE="{IP} Payload Compression Protocol {(IPComp)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2393,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This document describes a protocol intended to provide
lossless compression for Internet Protocol datagrams in an Internet
environment.",
URL="http://www.rfc-editor.org/rfc/rfc2393.txt"
}

@TECHREPORT{rfc2394,
AUTHOR="R. Pereira",
TITLE="{IP} Payload Compression Using {DEFLATE}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2394,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2394.txt"
}

@TECHREPORT{rfc2395,
AUTHOR="R. Friend and R. Monsour",
TITLE="{IP} Payload Compression Using {LZS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2395,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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 [IPCOMP].",
URL="http://www.rfc-editor.org/rfc/rfc2395.txt"
}

@TECHREPORT{rfc2396,
AUTHOR="T. Berners-Lee and R. Fielding and L. Masinter",
TITLE="Uniform Resource Identifiers {(URI):} Generic Syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2396,
PAGES=40,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2396.txt"
}

@TECHREPORT{rfc2397,
AUTHOR="L. Masinter",
TITLE={The {"}data{"} {URL} scheme},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2397,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT={A new URL scheme, {"}data{"}, is defined. It allows inclusion of
small data items as {"}immediate{"} data, as if it had been included
externally.},
URL="http://www.rfc-editor.org/rfc/rfc2397.txt"
}

@TECHREPORT{rfc2398,
AUTHOR="S. R. Parker and C. Schmechel",
TITLE="Some Testing Tools for {TCP} Implementors",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2398,
PAGES=15,
DAYS=15,
MONTH=aug,
YEAR=1998,
ABSTRACT="Available tools for testing TCP implementations are catalogued
by this memo. Hopefully disseminating this information will encourage
those responsible for building and maintaining TCP to make the best use
of available tests. The type of testing the tool provides, the type of
tests it is capable of doing, and its availability is enumerated.",
URL="http://www.rfc-editor.org/rfc/rfc2398.txt"
}

@TECHREPORT{rfc2401,
AUTHOR="S. A. Kent and R. Atkinson",
TITLE="Security Architecture for the Internet Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2401,
PAGES=66,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This memo specifies the base architecture for IPsec compliant
systems. The goal of the architecture is to provide various security
services for traffic at the IP layer, in both the IPv4 and IPv6
environments. This document describes the goals of such systems, their
components and how they fit together with each other and into the IP
environment. It also describes the security services offered by the
IPsec protocols, and how these services can be employed in the IP
environment.",
URL="http://www.rfc-editor.org/rfc/rfc2401.txt"
}

@TECHREPORT{rfc2402,
AUTHOR="S. A. Kent and R. Atkinson",
TITLE="{IP} Authentication Header",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2402,
PAGES=22,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT={The IP Authentication Header (AH) is used to provide
connectionless integrity and data origin authentication for IP datagrams
(hereafter referred to as just {"}authentication{"}), and to provide
protection against replays.},
URL="http://www.rfc-editor.org/rfc/rfc2402.txt"
}

@TECHREPORT{rfc2403,
AUTHOR="C. Madson and R. Glenn",
TITLE="The Use of {HMAC-MD5-96} within {ESP} and {AH}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2403,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This memo describes the use of the HMAC algorithm [RFC-2104]
in conjunction with the MD5 algorithm [RFC-1321] as an authentication
mechanism within the revised IPSEC Encapsulating Security Payload [ESP]
and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides
data origin authentication and integrity protection.",
URL="http://www.rfc-editor.org/rfc/rfc2403.txt"
}

@TECHREPORT{rfc2404,
AUTHOR="C. Madson and R. Glenn",
TITLE="The Use of {HMAC-SHA-1-96} within {ESP} and {AH}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2404,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This memo describes the use of the HMAC algorithm [RFC-2104]
in conjunction with the SHA-1 algorithm [FIPS-180-1] as an
authentication mechanism within the revised IPSEC Encapsulating Security
Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC
with SHA-1 provides data origin authentication and integrity protection.",
URL="http://www.rfc-editor.org/rfc/rfc2404.txt"
}

@TECHREPORT{rfc2405,
AUTHOR="C. Madson and N. Doraswamy",
TITLE="The {ESP} {DES-CBC} Cipher Algorithm With Explicit {IV}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2405,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2405.txt"
}

@TECHREPORT{rfc2406,
AUTHOR="S. A. Kent and R. Atkinson",
TITLE="{IP} Encapsulating Security Payload {(ESP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2406,
PAGES=22,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="The Encapsulating Security Payload (ESP) header is designed to
provide a mix of security services in IPv4 and IPv6.",
URL="http://www.rfc-editor.org/rfc/rfc2406.txt"
}

@TECHREPORT{rfc2407,
AUTHOR="D. Piper",
TITLE="The Internet {IP} Security Domain of Interpretation for {ISAKMP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2407,
PAGES=32,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="The Internet Security Association and Key Management Protocol
(ISAKMP) defines a framework for security association management and
cryptographic key establishment for the Internet. This framework
consists of defined exchanges, payloads, and processing guidelines that
occur within a given Domain of Interpretation (DOI). This document
defines the Internet IP Security DOI (IPSEC DOI), which instantiates
ISAKMP for use with IP when IP uses ISAKMP to negotiate security
associations.",
URL="http://www.rfc-editor.org/rfc/rfc2407.txt"
}

@TECHREPORT{rfc2408,
AUTHOR="D. Maughan and M. Schertler and M. Schneider and J. S. Turner",
TITLE="Internet Security Association and Key Management Protocol {(ISAKMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2408,
PAGES=86,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This memo describes a protocol utilizing security concepts
necessary for establishing Security Associations (SA) and cryptographic
keys in an Internet environment.",
URL="http://www.rfc-editor.org/rfc/rfc2408.txt"
}

@TECHREPORT{rfc2409,
AUTHOR="D. Harkins and D. Carrel",
TITLE="The Internet Key Exchange {(IKE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2409,
PAGES=41,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This document describes a protocol using part of Oakley and
part of SKEME in conjunction with ISAKMP to obtain authenticated keying
material for use with ISAKMP, and for other security associations such
as AH and ESP for the IETF IPsec DOI.",
URL="http://www.rfc-editor.org/rfc/rfc2409.txt"
}

@TECHREPORT{rfc2410,
AUTHOR="R. Glenn and S. A. Kent",
TITLE="The {NULL} Encryption Algorithm and Its Use With {IPsec}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2410,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2410.txt"
}

@TECHREPORT{rfc2411,
AUTHOR="R. Thayer and N. Doraswamy and R. Glenn",
TITLE="{IP} Security Document Roadmap",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2411,
PAGES=11,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2411.txt"
}

@TECHREPORT{rfc2412,
AUTHOR="H. Orman",
TITLE="The {OAKLEY} Key Determination Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2412,
PAGES=55,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2412.txt"
}

@TECHREPORT{rfc2413,
AUTHOR="S. Weibel and J. Kunze and C. Lagoze and M. Wolf",
TITLE="Dublin Core Metadata for Resource Discovery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2413,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="The Dublin Core Metadata Workshop Series began in 1995 with an
invitational workshop which brought together librarians, digital library
researchers, content experts, and text-markup experts to promote better
discovery standards for electronic resources. The Dublin Core is a
15-element set of descriptors that has emerged from this effort in
interdisciplinary and international consensus building. This is the
first of a set of Informational RFCs describing the Dublin Core. Its
purpose is to introduce the Dublin Core and to describe the consensus
reached on the semantics of each of the 15 elements.",
URL="http://www.rfc-editor.org/rfc/rfc2413.txt"
}

@TECHREPORT{rfc2414,
AUTHOR="M. Allman and S. Floyd and C. Partridge",
TITLE="Increasing {TCP's} Initial Window",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2414,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2414.txt"
}

@TECHREPORT{rfc2415,
AUTHOR="K. Poduri and K. Nichols",
TITLE="Simulation Studies of Increased Initial {TCP} Window Size",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2415,
PAGES=11,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2415.txt"
}

@TECHREPORT{rfc2416,
AUTHOR="T. Shepard and C. Partridge",
TITLE="When {TCP} Starts Up With Four Packets Into Only Three Buffers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2416,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2416.txt"
}

@TECHREPORT{rfc2418,
AUTHOR="S. Bradner",
TITLE="{IETF} Working Group Guidelines and Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2418,
PAGES=26,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2418.txt"
}

@TECHREPORT{rfc2419,
AUTHOR="K. Sklower and G. Meyer",
TITLE="The {PPP} {DES} Encryption Protocol, Version 2 {(DESE-bis)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2419,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="This document provides specific details for the use of the DES
standard for encrypting PPP encapsulated packets.",
URL="http://www.rfc-editor.org/rfc/rfc2419.txt"
}

@TECHREPORT{rfc2420,
AUTHOR="H. Kummert",
TITLE="The {PPP} {Triple-DES} Encryption Protocol {(3DESE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2420,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="This document provides specific details for the use of the
Triple-DES standard (3DES) for encrypting PPP encapsulated packets.",
URL="http://www.rfc-editor.org/rfc/rfc2420.txt"
}

@TECHREPORT{rfc2421,
AUTHOR="G. M. Vaudreuil and G. Parsons",
TITLE="Voice Profile for Internet Mail - version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2421,
PAGES=56,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="This document profiles Internet mail for voice messaging.",
URL="http://www.rfc-editor.org/rfc/rfc2421.txt"
}

@TECHREPORT{rfc2422,
AUTHOR="G. M. Vaudreuil and G. Parsons",
TITLE="Toll Quality Voice - 32 kbit/s {ADPCM} {MIME} Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2422,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="This document describes the registration of the MIME sub-type
audio/32KADPCM for toll quality audio. This audio encoding is defined by
the ITU-T in Recommendation G.726.",
URL="http://www.rfc-editor.org/rfc/rfc2422.txt"
}

@TECHREPORT{rfc2423,
AUTHOR="G. M. Vaudreuil and G. Parsons",
TITLE="{VPIM} Voice Message {MIME} Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2423,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="This document describes the registration of the MIME sub-type
multipart/voice-message for use with the Voice Profile for Internet Mail
(VPIM). A full description of usage can be found in the VPIM v2
specification.",
URL="http://www.rfc-editor.org/rfc/rfc2423.txt"
}

@TECHREPORT{rfc2424,
AUTHOR="G. M. Vaudreuil and G. Parsons",
TITLE="Content Duration {MIME} Header Definition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2424,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="This document describes the MIME header Content-Duration that
is intended for use with any timed media content (typically audio/* or
video/*).",
URL="http://www.rfc-editor.org/rfc/rfc2424.txt"
}

@TECHREPORT{rfc2425,
AUTHOR="T. Howes and M. Smith and F. Dawson",
TITLE="A {MIME} {Content-Type} for Directory Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2425,
PAGES=33,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="This document defines a MIME Content-Type for holding
directory information. The definition is independent of any particular
directory service or protocol. The text/directory Content-Type is
defined for holding a variety of directory information, for example,
name, or email address, or logo. The text/directory Content-Type can
also be used as the root body part in a multipart/related Content-Type
for handling more complicated situations, especially those in which
non-textual information that already has a natural MIME representation,
for example, a photograph or sound, is to be represented.",
URL="http://www.rfc-editor.org/rfc/rfc2425.txt"
}

@TECHREPORT{rfc2426,
AUTHOR="F. Dawson and T. Howes",
TITLE="vCard {MIME} Directory Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2426,
PAGES=42,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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 VCard representation of a white-pages directory entry
within the MIME Content-Type defined by the MIME-DIR document.",
URL="http://www.rfc-editor.org/rfc/rfc2426.txt"
}

@TECHREPORT{rfc2427,
AUTHOR="C. M. Brown and A. Malis",
TITLE="Multiprotocol Interconnect over Frame Relay",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2427,
PAGES=34,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="This memo describes an encapsulation method for carrying
network interconnect traffic over a Frame Relay backbone. It covers
aspects of both Bridging and Routing.",
URL="http://www.rfc-editor.org/rfc/rfc2427.txt"
}

@TECHREPORT{rfc2428,
AUTHOR="M. Allman and S. Ostermann and C. Metz",
TITLE="{FTP} Extensions for {IPv6} and {NATs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2428,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2428.txt"
}

@TECHREPORT{rfc2429,
EDITOR="  and L. Cline and G. Deisher",
TITLE="{RTP} Payload Format for the 1998 Version of {ITU-T} Rec",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2429,
PAGES=17,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="This document specifies an RTP payload header format
applicable to the transmission of video streams generated based on the
1998 version of ITU-T Recommendation H.263.",
URL="http://www.rfc-editor.org/rfc/rfc2429.txt"
}

@TECHREPORT{rfc2430,
AUTHOR="T. Li and Y. Rekhter",
TITLE="A Provider Architecture for Differentiated Services and Traffic Engineering
{(PASTE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2430,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="This document describes the Provider Architecture for
Differentiated Services and Traffic Engineering (PASTE) for Internet
Service Providers (ISPs).",
URL="http://www.rfc-editor.org/rfc/rfc2430.txt"
}

@TECHREPORT{rfc2431,
AUTHOR="D. Tynan",
TITLE="{RTP} Payload Format for {BT.656} Video Encoding",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2431,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="This document specifies the RTP payload format for
encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time
Transport Protocol (RTP).",
URL="http://www.rfc-editor.org/rfc/rfc2431.txt"
}

@TECHREPORT{rfc2432,
AUTHOR="K. Dubray",
TITLE="Terminology for {IP} Multicast Benchmarking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2432,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2432.txt"
}

@TECHREPORT{rfc2433,
AUTHOR="G. Zorn and S. Cobb",
TITLE="Microsoft {PPP} {CHAP} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2433,
PAGES=20,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="This document describes Microsoft's PPP CHAP dialect
(MS-CHAP), which extends the user authentication functionality provided
on Windows networks to remote workstations. MS-CHAP is closely derived
from the PPP Challenge Handshake Authentication Protocol described in
RFC 1994, which the reader should have at hand.",
URL="http://www.rfc-editor.org/rfc/rfc2433.txt"
}

@TECHREPORT{rfc2434,
AUTHOR="T. Narten and H. Alvestrand",
TITLE="Guidelines for Writing an {IANA} Considerations Section in {RFCs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2434,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2434.txt"
}

@TECHREPORT{rfc2435,
AUTHOR="L. Berc and W. Fenner and R. Frederick and S. McCanne and P. Stewart",
TITLE="{RTP} Payload Format for {JPEG-compressed} Video",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2435,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2435.txt"
}

@TECHREPORT{rfc2436,
AUTHOR="R. Brett and S. Bradner and G. Parsons",
TITLE="Collaboration between {ISOC/IETF} and {ITU-T}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2436,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="This document describes the collaboration process between the
ITU-T and ISOC/IETF. The process was documented by ITU-T at its TSAG
(Telecommunication Standardization Advisory Group) meeting in September
1998. All participants of this meeting (including Study Group chairmen
and the ISOC Vice President for Standards) assisted in the creation of
this document. Subsequently, it was sent to all ITU-T Study Groups and
ISOC/IETF to ensure that everyone was aware of the process. Feedback is
requested by the next meeting of TSAG in April 1999. This document is
identical to the document produced by TSAG.",
URL="http://www.rfc-editor.org/rfc/rfc2436.txt"
}

@TECHREPORT{rfc2437,
AUTHOR="B. Kaliski and J. Staddon",
TITLE="{PKCS} {#1:} {RSA} Cryptography Specifications Version {2.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2437,
PAGES=39,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="This document provides recommendations for the implementation
of public-key cryptography based on the RSA algorithm.",
URL="http://www.rfc-editor.org/rfc/rfc2437.txt"
}

@TECHREPORT{rfc2438,
AUTHOR="M. O'Dell and H. Alvestrand and B. Wijnen and S. Bradner",
TITLE="Advancement of {MIB} specifications on the {IETF} Standards Track",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2438,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT={The Internet Standards Process requires that all IETF
Standards Track specifications must have {"}multiple, independent, and
interoperable implementations{"} 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.},
URL="http://www.rfc-editor.org/rfc/rfc2438.txt"
}

@TECHREPORT{rfc2439,
AUTHOR="C. Villamizar and R. Chandra and R. Govindan",
TITLE="{BGP} Route Flap Damping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2439,
PAGES=37,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2439.txt"
}

@TECHREPORT{rfc2440,
AUTHOR="J. Callas and L. Donnerhacke and H. Finney and R. Thayer",
TITLE="{OpenPGP} Message Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2440,
PAGES=65,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2440.txt"
}

@TECHREPORT{rfc2441,
AUTHOR="D. Cohen",
TITLE="Working with Jon, Tribute delivered at {UCLA,} October {30,} 1998",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2441,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="A tribute by Danny Cohen to long-time friend and peer, Jon
Postel.",
URL="http://www.rfc-editor.org/rfc/rfc2441.txt"
}

@TECHREPORT{rfc2442,
AUTHOR="N. Freed and D. Newman and J. Belissen and M. Hoy",
TITLE="The Batch {SMTP} Media Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2442,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.,
[RFC-1847]) 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.",
URL="http://www.rfc-editor.org/rfc/rfc2442.txt"
}

@TECHREPORT{rfc2443,
AUTHOR="J. Luciani and A. Gallo",
TITLE="A Distributed {MARS} Service Using {SCSP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2443,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2443.txt"
}

@TECHREPORT{rfc2444,
AUTHOR="C. Newman",
TITLE="The {One-Time-Password} {SASL} Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2444,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2444.txt"
}

@TECHREPORT{rfc2445,
AUTHOR="F. Dawson and D. Stenerson",
TITLE="Internet Calendaring and Scheduling Core Object Specification (iCalendar)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2445,
PAGES=148,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2445.txt"
}

@TECHREPORT{rfc2446,
AUTHOR="S. Silverberg and S. Mansour and F. Dawson and R. Hopson",
TITLE="iCalendar {Transport-Independent} Interoperability Protocol {(iTIP)}
Scheduling Events, {BusyTime,} To-dos and Journal Entries",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2446,
PAGES=109,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2446.txt"
}

@TECHREPORT{rfc2447,
AUTHOR="F. Dawson and S. Mansour and S. Silverberg",
TITLE="iCalendar {Message-Based} Interoperability Protocol {(iMIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2447,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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 [iCAL] are composed using constructs from [RFC-822],
[RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].",
URL="http://www.rfc-editor.org/rfc/rfc2447.txt"
}

@TECHREPORT{rfc2448,
AUTHOR="M. Reha Civanlar and G. Cash and B. G. Haskell",
TITLE="{AT\&T's} Error Resilient Video Transmission Technique",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2448,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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\&T/Lucent patents.",
URL="http://www.rfc-editor.org/rfc/rfc2448.txt"
}

@TECHREPORT{rfc2449,
AUTHOR="R. Gellens and C. Newman and L. Lundblade",
TITLE="{POP3} Extension Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2449,
PAGES=19,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This memo updates RFC 1939 [POP3] to define a mechanism to
announce support for optional commands, extensions, and unconditional
server behavior. Included is an initial set of currently deployed
capabilities which vary between server implementations, and several new
capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE and
IMPLEMENTATION). This document also extends POP3 error messages so that
machine parsable codes can be provided to the client. An initial set of
response codes is included. In addition, an [ABNF] specification of POP3
commands and responses is defined.",
URL="http://www.rfc-editor.org/rfc/rfc2449.txt"
}

@TECHREPORT{rfc2450,
AUTHOR="R. Hinden",
TITLE="Proposed {TLA} and {NLA} Assignment Rule",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2450,
PAGES=11,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This document proposes rules for Top-Level Aggregation
Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as
defined in [AGGR]. These proposed rules apply to registries allocating
TLA ID's and to organizations receiving TLA ID's.",
URL="http://www.rfc-editor.org/rfc/rfc2450.txt"
}

@TECHREPORT{rfc2451,
AUTHOR="R. Pereira and R. Adams",
TITLE="The {ESP} {CBC-Mode} Cipher Algorithms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2451,
PAGES=14,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2451.txt"
}

@TECHREPORT{rfc2452,
AUTHOR="M. Daniele",
TITLE="{IP} Version 6 Management Information Base for the Transmission Control
Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2452,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
IPv6-based internets.",
URL="http://www.rfc-editor.org/rfc/rfc2452.txt"
}

@TECHREPORT{rfc2453,
AUTHOR="G. Malkin",
TITLE="{RIP} Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2453,
PAGES=39,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This document specifies an extension of the Routing
Information Protocol (RIP), as defined in RIP, to expand the amount of
useful information carried in RIP messages and to add a measure of
security.",
URL="http://www.rfc-editor.org/rfc/rfc2453.txt"
}

@TECHREPORT{rfc2454,
AUTHOR="M. Daniele",
TITLE="{IP} Version 6 Management Information Base for the User Datagram Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2454,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2454.txt"
}

@TECHREPORT{rfc2455,
AUTHOR="B. Clouston and B. W. Moore",
TITLE="Definitions of Managed Objects for {APPN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2455,
PAGES=140,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for monitoring and
controlling network devices with APPN (Advanced Peer-to-Peer Networking)
capabilities. This memo identifies managed objects for the APPN
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2455.txt"
}

@TECHREPORT{rfc2456,
AUTHOR="B. Clouston and B. W. Moore",
TITLE="Definitions of Managed Objects for {APPN} {TRAPS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2456,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for 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.",
URL="http://www.rfc-editor.org/rfc/rfc2456.txt"
}

@TECHREPORT{rfc2457,
AUTHOR="B. Clouston and B. W. Moore",
TITLE="Definitions of Managed Objects for Extended Border Node",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2457,
PAGES=28,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for 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.",
URL="http://www.rfc-editor.org/rfc/rfc2457.txt"
}

@TECHREPORT{rfc2458,
AUTHOR="H. Lu and M. Krishnaswamy and L. Conroy and S. M. Bellovin and F. Burg and
A. DeSimone and K. Tewani and P. J. Davidson",
TITLE="Toward the {PSTN/Internet} {Inter-Networking--Pre-PINT} Implementations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2458,
PAGES=60,
DAYS=15,
MONTH=nov,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2458.txt"
}

@TECHREPORT{rfc2460,
AUTHOR="S. E. Deering and R. Hinden",
TITLE="Internet Protocol, Version 6 {(IPv6)} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2460,
PAGES=39,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This document specifies version 6 of the Internet Protocol
(IPv6), also sometimes referred to as IP Next Generation or IPng.",
URL="http://www.rfc-editor.org/rfc/rfc2460.txt"
}

@TECHREPORT{rfc2461,
AUTHOR="T. Narten and E. Nordmark and W. Simpson",
TITLE="Neighbor Discovery for {IP} Version 6 {(IPv6)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2461,
PAGES=93,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2461.txt"
}

@TECHREPORT{rfc2462,
AUTHOR="S. Thomson and T. Narten",
TITLE="{IPv6} Stateless Address Autoconfiguration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2462,
PAGES=25,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2462.txt"
}

@TECHREPORT{rfc2463,
AUTHOR="A. Conta and S. E. Deering",
TITLE="Internet Control Message Protocol {(ICMPv6)} for the Internet Protocol
Version 6 {(IPv6)} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2463,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This document specifies a set of Internet Control Message
Protocol (ICMP) messages for use with version 6 of the Internet Protocol
(IPv6).",
URL="http://www.rfc-editor.org/rfc/rfc2463.txt"
}

@TECHREPORT{rfc2464,
AUTHOR="M. Crawford",
TITLE="Transmission of {IPv6} Packets over Ethernet Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2464,
PAGES=7,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This document specifies the frame format for transmission of
IPv6 packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on Ethernet networks. It also
specifies the content of the Source/Target Link-layer Address option
used in Router Solicitation, Router Advertisement, Neighbor
Solicitation, Neighbor Advertisement and Redirect messages when those
messages are transmitted on an Ethernet.",
URL="http://www.rfc-editor.org/rfc/rfc2464.txt"
}

@TECHREPORT{rfc2465,
AUTHOR="D. Haskin and S. Onishi",
TITLE="Management Information Base for {IP} Version {6:} Textual Conventions and
General Group",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2465,
PAGES=38,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2465.txt"
}

@TECHREPORT{rfc2466,
AUTHOR="D. Haskin and S. Onishi",
TITLE="Management Information Base for {IP} Version {6:} {ICMPv6} Group",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2466,
PAGES=16,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2466.txt"
}

@TECHREPORT{rfc2467,
AUTHOR="M. Crawford",
TITLE="Transmission of {IPv6} Packets over {FDDI} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2467,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This document specifies the frame format for transmission of
IPv6 packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on FDDI networks. It also specifies
the content of the Source/Target Link-layer Address option used in
Router Solicitation, Router Advertisement, Neighbor Solicitation,
Neighbor Advertisement and Redirect messages when those messages are
transmitted on an FDDI network.",
URL="http://www.rfc-editor.org/rfc/rfc2467.txt"
}

@TECHREPORT{rfc2468,
AUTHOR="V. G. Cerf",
TITLE="I {REMEMBER} {IANA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2468,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=1998,
ABSTRACT="Jon, our beloved IANA, is gone. Even as I write these words I
cannot quite grasp this stark fact. We had almost lost him once before
in 1991. Surely we knew he was at risk as are we all. But he had been
our rock, the foundation on which our every web search and email was
built, always there to mediate the random dispute, to remind us when our
documentation did not do justice to its subject, to make difficult
decisions with apparent ease, and to consult when careful consideration
was needed. We will survive our loss and we will remember. He has left a
monumental legacy for all Internauts to contemplate. Steadfast service
for decades, moving when others seemed paralyzed, always finding the
right course in a complex minefield of technical and sometimes political
obstacles.",
URL="http://www.rfc-editor.org/rfc/rfc2468.txt"
}

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

@TECHREPORT{rfc2470,
AUTHOR="M. Crawford and T. Narten and S. Thomas",
TITLE="Transmission of {IPv6} Packets over Token Ring Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2470,
PAGES=11,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This memo specifies the MTU and frame format for transmission
of IPv6 packets on Token Ring networks. It also specifies the method of
forming IPv6 link-local addresses on Token Ring networks and the content
of the Source/Target Link-layer Address option used the Router
Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and
Neighbor Advertisement messages when those messages are transmitted on a
Token Ring network.",
URL="http://www.rfc-editor.org/rfc/rfc2470.txt"
}

@TECHREPORT{rfc2471,
AUTHOR="R. Hinden and R. Fink and J. Postel Deceased)",
TITLE="{IPv6} Testing Address Allocation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2471,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This document describes an allocation plan for IPv6 addresses
to be used in testing IPv6 prototype software. These addresses are
temporary and will be reclaimed in the future. Any IPv6 system using
these addresses will have to renumber at some time in the future. These
addresses will not to be routable in the Internet other than for IPv6
testing.",
URL="http://www.rfc-editor.org/rfc/rfc2471.txt"
}

@TECHREPORT{rfc2472,
AUTHOR="D. Haskin and E. B. Allen",
TITLE="{IP} Version 6 over {PPP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2472,
PAGES=14,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2472.txt"
}

@TECHREPORT{rfc2473,
AUTHOR="A. Conta and S. E. Deering",
TITLE="Generic Packet Tunneling in {IPv6} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2473,
PAGES=36,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2473.txt"
}

@TECHREPORT{rfc2474,
AUTHOR="K. Nichols and S. Blake and F. Baker and D. L. Black",
TITLE="Definition of the Differentiated Services Field {(DS} Field) in the {IPv4}
and {IPv6} Headers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2474,
PAGES=20,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2474.txt"
}

@TECHREPORT{rfc2475,
AUTHOR="S. Blake and D. L. Black and M. Carlson and E. Davies and Z. Wang and W.
Weiss",
TITLE="An Architecture for Differentiated Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2475,
PAGES=36,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="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
[DSFIELD]. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2475.txt"
}

@TECHREPORT{rfc2476,
AUTHOR="R. Gellens and J. Klensin",
TITLE="Message Submission",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2476,
PAGES=15,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This memo describes a low cost, deterministic means for
messages to be identified as submissions, and specifies what actions are
to be taken by a submission server.",
URL="http://www.rfc-editor.org/rfc/rfc2476.txt"
}

@TECHREPORT{rfc2478,
AUTHOR="E. Baize and D. Pinkas",
TITLE="The Simple and Protected {GSS-API} Negotiation Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2478,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT="This document specifies a Security Negotiation Mechanism for
the Generic Security Service Application Program Interface (GSS-API).",
URL="http://www.rfc-editor.org/rfc/rfc2478.txt"
}

@TECHREPORT{rfc2479,
AUTHOR="C. J. Adams",
TITLE="Independent Data Unit Protection Generic Security Service Application
Program Interface {(IDUP-GSS-API)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2479,
PAGES=70,
DAYS=15,
MONTH=dec,
YEAR=1998,
ABSTRACT={The IDUP-GSS-API extends the GSS-API [RFC-2078] 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
{"}receivers{"} 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.},
URL="http://www.rfc-editor.org/rfc/rfc2479.txt"
}

@TECHREPORT{rfc2246,
AUTHOR="T. Dierks and C. Allen",
TITLE="The {TLS} Protocol Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2246,
PAGES=80,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2246.txt"
}

@TECHREPORT{rfc2299,
AUTHOR="A. Ramos",
TITLE="Request for Comments Summary",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2299,
PAGES=24,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
2200 through RFCs 2299. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2299.txt"
}

@TECHREPORT{rfc2459,
AUTHOR="R. Housley and W. Ford and W. Polk and D. Solo",
TITLE="Internet {X.509} Public Key Infrastructure Certificate and {CRL} Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2459,
PAGES=129,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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 X.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.",
URL="http://www.rfc-editor.org/rfc/rfc2459.txt"
}

@TECHREPORT{rfc2477,
AUTHOR="B. Aboba and G. Zorn",
TITLE="Criteria for Evaluating Roaming Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2477,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2477.txt"
}

@TECHREPORT{rfc2480,
AUTHOR="N. Freed",
TITLE="Gateways and {MIME} Security Multiparts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2480,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This document examines the problems associated with use of
MIME security multiparts and gateways to non-MIME environments. A set of
requirements for gateway behavior are defined which provide facilities
necessary to properly accomodate the transfer of security multiparts
through gateways.",
URL="http://www.rfc-editor.org/rfc/rfc2480.txt"
}

@TECHREPORT{rfc2481,
AUTHOR="K. G. Ramakrishnan and S. Floyd",
TITLE="A Proposal to add Explicit Congestion Notification {(ECN)} to {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2481,
PAGES=25,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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'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.",
URL="http://www.rfc-editor.org/rfc/rfc2481.txt"
}

@TECHREPORT{rfc2482,
AUTHOR="K. Whistler and G. C. Adams",
TITLE="Language Tagging in Unicode Plain Text",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2482,
PAGES=14,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This document proposed a mechanism for language tagging in
[UNICODE] plain text. A set of special-use tag characters on Plane 14 of
[ISO10646] (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).",
URL="http://www.rfc-editor.org/rfc/rfc2482.txt"
}

@TECHREPORT{rfc2483,
AUTHOR="M. Mealling and R. W. Daniel",
TITLE="{URI} Resolution Services Necessary for {URN} Resolution",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2483,
PAGES=16,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2483.txt"
}

@TECHREPORT{rfc2484,
AUTHOR="G. Zorn",
TITLE="{PPP} {LCP} Internationalization Configuration Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2484,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2484.txt"
}

@TECHREPORT{rfc2485,
AUTHOR="S. Drach",
TITLE="{DHCP} Option for The Open Group's User Authentication Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2485,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2485.txt"
}

@TECHREPORT{rfc2486,
AUTHOR="B. Aboba and M. Beadles",
TITLE="The Network Access Identifier",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2486,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2486.txt"
}

@TECHREPORT{rfc2487,
AUTHOR="P. Hoffman",
TITLE="{SMTP} Service Extension for Secure {SMTP} over {TLS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2487,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This document describes an extension to the SMTP service that
allows an SMTP server and client to use transport-layer security to
provide private, authenticated communication over the Internet. This
gives SMTP agents the ability to protect some or all of their
communications from eavesdroppers and attackers.",
URL="http://www.rfc-editor.org/rfc/rfc2487.txt"
}

@TECHREPORT{rfc2488,
AUTHOR="M. Allman and D. Glover and L. Sanchez",
TITLE="Enhancing {TCP} Over Satellite Channels using Standard Mechanisms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2488,
PAGES=19,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2488.txt"
}

@TECHREPORT{rfc2489,
AUTHOR="R. E. Droms",
TITLE="Procedure for Defining New {DHCP} Options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2489,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT={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.{"}
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.},
URL="http://www.rfc-editor.org/rfc/rfc2489.txt"
}

@TECHREPORT{rfc2490,
AUTHOR="M. Pullen and R. Malghan and L. Lavu and G. Duan and J. Ma and H. Nah",
TITLE="A Simulation Model for {IP} Multicast with {RSVP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2490,
PAGES=31,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2490.txt"
}

@TECHREPORT{rfc2491,
AUTHOR="G. Armitage and P. Schulter and M. Jork and G. Harter",
TITLE="{IPv6} over {Non-Broadcast} Multiple Access {(NBMA)} networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2491,
PAGES=44,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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 'shortcut' NBMA forwarding paths when
dynamically signaled NBMA links are available. Operations over
administratively configured Point to Point NBMA links are also
described. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2491.txt"
}

@TECHREPORT{rfc2492,
AUTHOR="G. Armitage and P. Schulter and M. Jork",
TITLE="{IPv6} over {ATM} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2492,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT={This document is a companion to the ION working group's
architecture document, {"}IPv6 over Non Broadcast Multiple Access (NBMA)
networks{"}. 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 'shortcut' ATM forwarding paths (when
using SVCs). Operation over administratively configured Point to Point
PVCs is also supported.},
URL="http://www.rfc-editor.org/rfc/rfc2492.txt"
}

@TECHREPORT{rfc2493,
AUTHOR="K. Tesink",
TITLE="Textual Conventions for {MIB} Modules Using Performance History Based on 15
Minute Intervals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2493,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This document defines a set of Textual Conventions for MIB
modules which make use of performance history data based on 15 minute
intervals.",
URL="http://www.rfc-editor.org/rfc/rfc2493.txt"
}

@TECHREPORT{rfc2494,
EDITOR="D. Fowler",
TITLE="Definitions of Managed Objects for the {DS0} and {DS0} Bundle Interface
Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2494,
PAGES=25,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing 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.",
URL="http://www.rfc-editor.org/rfc/rfc2494.txt"
}

@TECHREPORT{rfc2495,
EDITOR="D. Fowler",
TITLE="Definitions of Managed Objects for the {DS1,} {E1,} {DS2} and {E2}
Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2495,
PAGES=75,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing 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.",
URL="http://www.rfc-editor.org/rfc/rfc2495.txt"
}

@TECHREPORT{rfc2496,
EDITOR="D. Fowler",
TITLE="Definitions of Managed Object for the {DS3/E3} Interface Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2496,
PAGES=60,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing 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.",
URL="http://www.rfc-editor.org/rfc/rfc2496.txt"
}

@TECHREPORT{rfc2497,
AUTHOR="I. Souvatzis",
TITLE="Transmission of {IPv6} Packets over {ARCnet} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2497,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This memo specifies a frame format for transmission of IPv6
[IPV6] packets and the method of forming IPv6 link-local and statelessly
autoconfigured addresses on ARCnet networks. It also specifies the
content of the Source/Target Link-layer Address option used by the
Router Solicitation, Router Advertisement, Neighbor Solicitation,
Neighbor Advertisement and Redirect messages described in [DISC], when
those messages are transmitted on an ARCnet.",
URL="http://www.rfc-editor.org/rfc/rfc2497.txt"
}

@TECHREPORT{rfc2498,
AUTHOR="J. Mahdavi and V. Paxson",
TITLE="{IPPM} Metrics for Measuring Connectivity",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2498,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="This memo defines a series of metrics for connectivity between
a pair of Internet hosts. It builds on notions introduced and discussed
in RFC 2330, the IPPM framework document. The reader is assumed to be
familiar with that document.",
URL="http://www.rfc-editor.org/rfc/rfc2498.txt"
}

@TECHREPORT{rfc2500,
AUTHOR="J. F. Reynolds and R. Braden",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2500,
PAGES=28,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT={This memo summarizes the status of Internet protocols and
specifications. It is published by the RFC Editor in accordance with
Section 2.1 of {"}The Internet Standards Process -- Revision 3{"}, RFC
2026,
which specifies the rules and procedures by which all Internet stnadards
are set. This memo is prepared by the RFC Editor for the IESG and IAB.
It is a member of a series of summary memos that are published
approximately every one hundred RFCs; please see www.rfc-editor.org.},
URL="http://www.rfc-editor.org/rfc/rfc2500.txt"
}

@TECHREPORT{rfc2501,
AUTHOR="S. Corson and J. P. Macker",
TITLE="Mobile Ad hoc Networking {(MANET):} Routing Protocol Performance Issues and
Evaluation Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2501,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2501.txt"
}

@TECHREPORT{rfc2502,
AUTHOR="M. Pullen and M. Myjak and C. Bouwens",
TITLE="Limitations of Internet Protocol Suite for Distributed Simulation the Large
Multicast Environment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2502,
PAGES=11,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2502.txt"
}

@TECHREPORT{rfc2503,
AUTHOR="R. Moulton and M. H. Needleman",
TITLE="{MIME} Types for Use with the {ISO} {ILL} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2503,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This memorandum describes a set of MIME types for use with the
ISO Interlibrary Loan Protocol (ISO 10160/10161).",
URL="http://www.rfc-editor.org/rfc/rfc2503.txt"
}

@TECHREPORT{rfc2504,
AUTHOR="E. Guttman and L. Leong and G. Malkin",
TITLE="Users' Security Handbook",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2504,
PAGES=33,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="The Users' 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.",
URL="http://www.rfc-editor.org/rfc/rfc2504.txt"
}

@TECHREPORT{rfc2505,
AUTHOR="G. Lindberg",
TITLE="{Anti-Spam} Recommendations for {SMTP} {MTAs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2505,
PAGES=24,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2505.txt"
}

@TECHREPORT{rfc2506,
AUTHOR="K. Holtman and A. Mutz and T. Hardie",
TITLE="Media Feature Tag Registration Procedure",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2506,
PAGES=12,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This document defines a registration procedure which uses the
Internet Assigned Numbers Authority (IANA) as a central registry for the
media feature vocabulary.",
URL="http://www.rfc-editor.org/rfc/rfc2506.txt"
}

@TECHREPORT{rfc2507,
AUTHOR="M. Degermark and B. Nordgren and S. Pink",
TITLE="{IP} Header Compression",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2507,
PAGES=47,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This document describes how to compress multiple IP headers
and TCP and UDP headers per hop over point to point links. The methods
can be applied to of IPv6 base and extension headers, IPv4 headers, TCP
and UDP headers, and encapsulated IPv6 and IPv4 headers.",
URL="http://www.rfc-editor.org/rfc/rfc2507.txt"
}

@TECHREPORT{rfc2508,
AUTHOR="S. Casner and V. Jacobson",
TITLE="Compressing {IP/UDP/RTP} Headers for {Low-Speed} Serial Links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2508,
PAGES=24,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This document describes a method for compressing the headers
of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In
many cases, all three headers can be compressed to 2-4 bytes.",
URL="http://www.rfc-editor.org/rfc/rfc2508.txt"
}

@TECHREPORT{rfc2509,
AUTHOR="M. Engan and S. Casner and C. Bormann",
TITLE="{IP} Header Compression over {PPP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2509,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This document describes an option for negotiating the use of
header compression on IP datagrams transmitted over the Point-to-Point
Protocol [RFC1661]. It defines extensions to the PPP Control Protocols
for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied
to IPv4 and IPv6 datagrams in combination with TCP, UDP and for IPv4 and
IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and
IPv6 datagrams in combination with TCP, UDP and RTP transport protocols
as specified in [IPHC] and [CRTP].",
URL="http://www.rfc-editor.org/rfc/rfc2509.txt"
}

@TECHREPORT{rfc2510,
AUTHOR="C. J. Adams and S. Farrell",
TITLE="Internet {X.509} Public Key Infrastructure Certificate Management Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2510,
PAGES=72,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2510.txt"
}

@TECHREPORT{rfc2511,
AUTHOR="M. Myers and C. J. Adams and D. Solo and D. Kemp",
TITLE="Internet {X.509} Certificate Request Message Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2511,
PAGES=25,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2511.txt"
}

@TECHREPORT{rfc2512,
AUTHOR="K. McCloghrie and J. Heinanen and W. Greene and A. Prasad",
TITLE="Accounting Information for {ATM} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2512,
PAGES=15,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. A separate memo defines managed objects, in a manner
independent of the type of network, for controlling the selection,
collection and storage of accounting information into files for later
retrieval via a file transfer protocol. This memo defines a set of
ATM-specific accounting information which can be collected for
connections on ATM networks.",
URL="http://www.rfc-editor.org/rfc/rfc2512.txt"
}

@TECHREPORT{rfc2513,
AUTHOR="K. McCloghrie and J. Heinanen and W. Greene and A. Prasad",
TITLE="Managed Objects for Controlling the Collection and Storage of Accounting
Information for {Connection-Oriented} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2513,
PAGES=29,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
controlling the collection and storage of accounting information for
connection-oriented networks such as ATM. The accounting data is
collected into files for later retrieval via a file transfer protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2513.txt"
}

@TECHREPORT{rfc2514,
AUTHOR="M. Noto and E. M. Spiegel and K. Tesink",
TITLE="Definitions of Textual Conventions and {OBJECT-IDENTITIES} for {ATM}
Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2514,
PAGES=20,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This memo describes Textual Conventions and OBJECT-IDENTITIES
used for managing ATM-based interfaces, devices, networks and services.",
URL="http://www.rfc-editor.org/rfc/rfc2514.txt"
}

@TECHREPORT{rfc2515,
AUTHOR="K. Tesink",
TITLE="Definitions of Managed Objects for {ATM} Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2515,
PAGES=87,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing
ATM-based interfaces, devices, networks and services.",
URL="http://www.rfc-editor.org/rfc/rfc2515.txt"
}

@TECHREPORT{rfc2516,
AUTHOR="L. A. Mamakos and K. Lidl and J. Evarts and D. Carrel and D. Simone and R.
M. Wheeler",
TITLE="A Method for Transmitting {PPP} Over Ethernet {(PPPoE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2516,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links.
This document describes how to build PPP sessions and encapsulate PPP
packets over Ethernet.",
URL="http://www.rfc-editor.org/rfc/rfc2516.txt"
}

@TECHREPORT{rfc2517,
AUTHOR="R. Moats and R. Huber",
TITLE="Building Directories from {DNS:} Experiences from {WWWSeeker}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2517,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2517.txt"
}

@TECHREPORT{rfc2518,
AUTHOR="Y. Goland and E. Whitehead and A. Faizi and S. Carter and D. Jensen",
TITLE="{HTTP} Extensions for Distributed Authoring {--} {WEBDAV}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2518,
PAGES=94,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2518.txt"
}

@TECHREPORT{rfc2519,
AUTHOR="E. H. Chen and J. Stewart",
TITLE="A Framework for {Inter-Domain} Route Aggregation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2519,
PAGES=13,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2519.txt"
}

@TECHREPORT{rfc2520,
AUTHOR="J. Luciani and H. Suzuki and N. Doraswamy and D. Horton",
TITLE="{NHRP} with Mobile {NHCs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2520,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="This document describes an extension to NHRP which would allow
Mobile NHCs to perform a registration with and attach to an NHS in their
home LIS in an authenticated manner.",
URL="http://www.rfc-editor.org/rfc/rfc2520.txt"
}

@TECHREPORT{rfc2521,
AUTHOR="P. Karn and W. Simpson",
TITLE="{ICMP} Security Failures Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2521,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This mechanism is intended for use with the Internet Security
Protocols [RFC-1825 et sequitur] for authentication and privacy. For
statically configured Security Associations, these messages indicate
that the operator needs to manually reconfigure, or is attempting an
unauthorized operation. These messages may also be used to trigger
automated session-key management.",
URL="http://www.rfc-editor.org/rfc/rfc2521.txt"
}

@TECHREPORT{rfc2522,
AUTHOR="P. Karn and W. Simpson",
TITLE="Photuris: {Session-Key} Management Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2522,
PAGES=76,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2522.txt"
}

@TECHREPORT{rfc2523,
AUTHOR="P. Karn and W. Simpson",
TITLE="Photuris: Extended Schemes and Attributes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2523,
PAGES=19,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="Photuris is a session-key management protocol. Extensible
Exchange-Schemes are provided to enable future implementation changes
without affecting the basic protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2523.txt"
}

@TECHREPORT{rfc2524,
AUTHOR="M. Banan",
TITLE="Neda's Efficient Mail Submission and Delivery {(EMSD)} Protocol
Specification Version {1.3}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2524,
PAGES=83,
DAYS=15,
MONTH=feb,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2524.txt"
}

@TECHREPORT{rfc2525,
AUTHOR="V. Paxson and M. Allman and S. Dawson and W. Fenner and J. Griner and I.
Heavens and K. Lahey and J. Semke",
TITLE="Known {TCP} Implementation Problems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2525,
PAGES=61,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This memo catalogs a number of known TCP implementation
problems. The goal in doing so is to improve conditions in the existing
Internet by enhancing the quality of current TCP/IP implementations. It
is hoped that both performance and correctness issues can be resolved by
making implementors aware of the problems and their solutions. In the
long term, it is hoped that this will provide a reduction in unnecessary
traffic on the network, the rate of connection failures due to protocol
errors, and load on network servers due to time spent processing both
unsuccessful connections and retransmitted data. This will help to
ensure the stability of the global Internet.",
URL="http://www.rfc-editor.org/rfc/rfc2525.txt"
}

@TECHREPORT{rfc2526,
AUTHOR="David B. Johnson and S. E. Deering",
TITLE="Reserved {{IPv6}} Subnet Anycast Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2526,
MONTH=mar,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2526.txt"
}

@TECHREPORT{rfc2527,
AUTHOR="S. Chokhani and W. Ford",
TITLE="Internet {X.509} Public Key Infrastructure Certificate Policy and
Certification Practices Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2527,
PAGES=45,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2527.txt"
}

@TECHREPORT{rfc2528,
AUTHOR="R. Housley and W. Polk",
TITLE="Internet {X.509} Public Key Infrastructure Representation of Key Exchange
Algorithm {(KEA)} Keys in Internet {X.509} Public Key Infrastructure
Certificates",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2528,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2528.txt"
}

@TECHREPORT{rfc2529,
AUTHOR="B. E. Carpenter and C. Jung",
TITLE="Transmission of {IPv6} over {IPv4} Domains without Explicit Tunnels",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2529,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This memo specifies the frame format for transmission of IPv6
[IPV6] packets and the method of forming IPv6 link-local addresses over
IPv4 domains. It also specifies the content of the Source/Target
Link-layer Address option used in the Router Solicitation, Router
Advertisement, Neighbor Solicitation, and Neighbor Advertisement and
Redirect messages, when those messages are transmitted on an IPv4
multicast network.",
URL="http://www.rfc-editor.org/rfc/rfc2529.txt"
}

@TECHREPORT{rfc2530,
AUTHOR="D. Wing",
TITLE="Indicating Supported Media Features Using Extensions to {DSN} and {MDN}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2530,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This memo describes a format for generating Message
Disposition Notifications [RFC2298] and Delivery Status Notifications
[RFC1894] which contain such information. This information can be used
by senders to avoid exceeding the recipient's capabilities when sending
subsequent messages.",
URL="http://www.rfc-editor.org/rfc/rfc2530.txt"
}

@TECHREPORT{rfc2531,
AUTHOR="G. Klyne and L. McIntyre",
TITLE="Content Feature Schema for Internet Fax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2531,
PAGES=51,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2531.txt"
}

@TECHREPORT{rfc2532,
AUTHOR="L. Masinter and D. Wing",
TITLE="Extended Facsimile Using Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2532,
PAGES=12,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT={This document describes extensions to {"}Simple Mode of
Facsimile Using Internet Mail{"} [RFC2305] and describes additional
features, including transmission of enhanced document characteristics
(higher resolution, color) and confirmation of delivery and processing.},
URL="http://www.rfc-editor.org/rfc/rfc2532.txt"
}

@TECHREPORT{rfc2533,
AUTHOR="G. Klyne",
TITLE="A Syntax for Describing Media Feature Sets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2533,
PAGES=37,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2533.txt"
}

@TECHREPORT{rfc2534,
AUTHOR="L. Masinter and D. Wing and A. Mutz and K. Holtman",
TITLE="Media Features for Display, Print, and Fax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2534,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2534.txt"
}

@TECHREPORT{rfc2535,
AUTHOR="D. Eastlake 3rd",
TITLE="Domain Name System Security Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2535,
PAGES=47,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2535.txt"
}

@TECHREPORT{rfc2536,
AUTHOR="D. Eastlake 3rd",
TITLE="{DSA} {KEYs} and {SIGs} in the Domain Name System {(DNS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2536,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2536.txt"
}

@TECHREPORT{rfc2537,
AUTHOR="D. Eastlake 3rd",
TITLE="{RSA/MD5} {KEYs} and {SIGs} in the Domain Name System {(DNS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2537,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2537.txt"
}

@TECHREPORT{rfc2538,
AUTHOR="D. Eastlake 3rd and O. Gudmundsson",
TITLE="Storing Certificates in the Domain Name System {(DNS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2538,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2538.txt"
}

@TECHREPORT{rfc2539,
AUTHOR="D. Eastlake 3rd",
TITLE="Storage of {Diffie-Hellman} Keys in the Domain Name System {(DNS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2539,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="A standard method for storing Diffie-Hellman keys in the
Domain Name System is described which utilizes DNS KEY resource records.",
URL="http://www.rfc-editor.org/rfc/rfc2539.txt"
}

@TECHREPORT{rfc2540,
AUTHOR="D. Eastlake 3rd",
TITLE="Detached Domain Name System {(DNS)} Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2540,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2540.txt"
}

@TECHREPORT{rfc2541,
AUTHOR="D. Eastlake 3rd",
TITLE="{DNS} Security Operational Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2541,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2541.txt"
}

@TECHREPORT{rfc2542,
AUTHOR="L. Masinter",
TITLE="Terminology and Goals for Internet Fax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2542,
PAGES=20,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2542.txt"
}

@TECHREPORT{rfc2543,
AUTHOR="M. Handley and Henning Schulzrinne and Eve M Schooler and J. Rosenberg",
TITLE="{SIP:} Session Initiation Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2543,
PAGES=153,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2543.txt"
}

@TECHREPORT{rfc2544,
AUTHOR="S. Bradner and J. McQuaid",
TITLE="Benchmarking Methodology for Network Interconnect Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2544,
PAGES=31,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This document is a republication of RFC 1944 correcting the
values for the IP addresses which were assigned to be used as the
default addresses for networking test equipment. (See section C.2.2 ).
This RFC replaces and obsoletes RFC 1944. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2544.txt"
}

@TECHREPORT{rfc2545,
AUTHOR="P. Marques and F. Dupont",
TITLE="Use of {BGP-4} Multiprotocol Extensions for {IPv6} {Inter-Domain} Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2545,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="BGP-4 Multiprotocol Extensions [BGP-MP] defines 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.",
URL="http://www.rfc-editor.org/rfc/rfc2545.txt"
}

@TECHREPORT{rfc2546,
AUTHOR="A. Durand and B. Buclin",
TITLE="6Bone Routing Practice",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2546,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This memo identifies guidelines on how 6Bone sites might
operate, so that the 6Bone can remain a quality experimentation
environment and to avoid pathological situations that have been
encountered in the past. It defines the 'best current practice'
acceptable in the 6Bone for the configuration of both Interior Gateway
Protocols (such as RIPng [RFC 2080]) and Exterior Gateway Protocols
(like BGP4+ [RFC 2283]).",
URL="http://www.rfc-editor.org/rfc/rfc2546.txt"
}

@TECHREPORT{rfc2547,
AUTHOR="E. C. Rosen and Y. Rekhter",
TITLE="{BGP/MPLS} {VPNs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2547,
PAGES=25,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2547.txt"
}

@TECHREPORT{rfc2548,
AUTHOR="G. Zorn",
TITLE="Microsoft Vendor-specific {RADIUS} Attributes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2548,
PAGES=41,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2548.txt"
}

@TECHREPORT{rfc2549,
AUTHOR="D. Waitzman",
TITLE="{IP} over Avian Carriers with Quality of Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2549,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT={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},
URL="http://www.rfc-editor.org/rfc/rfc2549.txt"
}

@TECHREPORT{rfc2550,
AUTHOR="S. Glassman and M. Manasse and J. C. Mogul",
TITLE="{Y10K} and Beyond",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2550,
PAGES=14,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2550.txt"
}

@TECHREPORT{rfc2551,
AUTHOR="S. Bradner",
TITLE="The Roman Standards Process {--} Revision {III}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2551,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2551.txt"
}

@TECHREPORT{rfc2552,
AUTHOR="M. Blinov and M. Bessonov and C. Clissmann",
TITLE="Architecture for the Information Brokerage in the {ACTS} Project {GAIA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2552,
PAGES=30,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2552.txt"
}

@TECHREPORT{rfc2553,
AUTHOR="R. Gilligan and S. Thomson and J. Bound and W. Richard Stevens",
TITLE="Basic Socket Interface Extensions for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2553,
PAGES=41,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2553.txt"
}

@TECHREPORT{rfc2554,
AUTHOR="J. Myers",
TITLE="{SMTP} Service Extension for Authentication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2554,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This document defines an SMTP service extension [ESMTP]
whereby an SMTP client may indicate an authentication mechanism to the
server, perform an authentication protocol exchange, and optionally
negotiate a security layer for subsequent protocol interactions. This
extension is a profile of the Simple Authentication and Security Layer
[SASL].",
URL="http://www.rfc-editor.org/rfc/rfc2554.txt"
}

@TECHREPORT{rfc2555,
AUTHOR="Rfc Editor and et al",
TITLE="30 Years of {RFCs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2555,
PAGES=18,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="History and reflections on the Request for Comments (RFC)
document series, and the people who made it possible, on its 30th
anniversary.",
URL="http://www.rfc-editor.org/rfc/rfc2555.txt"
}

@TECHREPORT{rfc2556,
AUTHOR="S. Bradner",
TITLE="{OSI} connectionless transport services on top of {UDP} Applicability
Statement for Historic Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2556,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT={RFC 1240, {"}OSI connectionless transport services on top of
UDP{"}, was published as a Proposed Standard in June 1991 but at this time
there do not seem to be any implementations which follow RFC 1240. In
addition there is a growing concern over using UDP-based transport
protocols in environments where congestion is a possibility.},
URL="http://www.rfc-editor.org/rfc/rfc2556.txt"
}

@TECHREPORT{rfc2557,
AUTHOR="J. Palme and A. Hopmann and N. Shelness",
TITLE="{MIME} Encapsulation of Aggregate Documents, such as {HTML} {(MHTML)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2557,
PAGES=28,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2557.txt"
}

@TECHREPORT{rfc2558,
AUTHOR="K. Tesink",
TITLE="Definitions of Managed Objects for the {SONET/SDH} Interface Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2558,
PAGES=74,
DAYS=15,
MONTH=mar,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces.
This document is a companion to the documents that define Managed
Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types.",
URL="http://www.rfc-editor.org/rfc/rfc2558.txt"
}

@TECHREPORT{rfc2559,
AUTHOR="S. Boeyen and T. Howes and P. Richard",
TITLE="Internet {X.509} Public Key Infrastructure Operational Protocols - {LDAPv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2559,
PAGES=13,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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. This document is the product of the
PKIX Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2559.txt"
}

@TECHREPORT{rfc2560,
AUTHOR="M. Myers and R. Ankney and A. Malpani and S. Galperin and C. J. Adams",
TITLE="{X.509} Internet Public Key Infrastructure Online Certificate Status
Protocol - {OCSP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2560,
PAGES=23,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2560.txt"
}

@TECHREPORT{rfc2561,
AUTHOR="K. White and R. Moore",
TITLE="Base Definitions of Managed Objects for {TN3270E} Using {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2561,
PAGES=56,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2561.txt"
}

@TECHREPORT{rfc2562,
AUTHOR="K. White and R. Moore",
TITLE="Definitions of Protocol and Managed Objects for {TN3270E} Response Time
Collection Using {SMIv2} {(TN3270E-RT-MIB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2562,
PAGES=49,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2562.txt"
}

@TECHREPORT{rfc2563,
AUTHOR="R. Troll",
TITLE="{DHCP} Option to Disable Stateless {Auto-Configuration} in {IPv4} Clients",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2563,
PAGES=9,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2563.txt"
}

@TECHREPORT{rfc2564,
AUTHOR="C. Kalbfleisch and C. Krupczak and R. Presuhn and J. Saperia",
TITLE="Application Management {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2564,
PAGES=86,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2564.txt"
}

@TECHREPORT{rfc2565,
EDITOR="R. Herriot and S. Butler and P. G. Moore",
TITLE="Internet Printing Protocol/1.0: Encoding and Transport",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2565,
PAGES=37,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT={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{"}.},
URL="http://www.rfc-editor.org/rfc/rfc2565.txt"
}

@TECHREPORT{rfc2566,
AUTHOR="R. deBry and T. Hastings and R. Herriot and S. Isaacson and P. Powell",
TITLE="Internet Printing Protocol/1.0: Model and Semantics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2566,
PAGES=173,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2566.txt"
}

@TECHREPORT{rfc2567,
AUTHOR="F. Wright",
TITLE="Design Goals for an Internet Printing Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2567,
PAGES=43,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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 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",
URL="http://www.rfc-editor.org/rfc/rfc2567.txt"
}

@TECHREPORT{rfc2568,
AUTHOR="S. Zilles",
TITLE="Rationale for the Structure of the Model and Protocol for the Internet
Printing Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2568,
PAGES=10,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2568.txt"
}

@TECHREPORT{rfc2569,
EDITOR="R. Herriot and T. Hastings and N. Jacobs",
TITLE="Mapping between {LPD} and {IPP} Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2569,
PAGES=28,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2569.txt"
}

@TECHREPORT{rfc2570,
AUTHOR="J. D. Case and R. Mundy and D. Partain and B. Stewart",
TITLE="Introduction to Version 3 of the Internet-standard Network Management
Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2570,
PAGES=23,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2570.txt"
}

@TECHREPORT{rfc2571,
AUTHOR="B. Wijnen and D. Harrington and R. Presuhn",
TITLE="An Architecture for Describing {SNMP} Management Frameworks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2571,
PAGES=62,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="This document describes an architecture for describing SNMP
Management Frameworks. The architecture is designed to be modular to
allow the evolution of the SNMP protocol standards over time. The major
portions of the architecture are an SNMP engine containing a Message
Processing Subsystem, a Security Subsystem and an Access Control
Subsystem, and possibly multiple SNMP applications which provide
specific functional processing of management data.",
URL="http://www.rfc-editor.org/rfc/rfc2571.txt"
}

@TECHREPORT{rfc2572,
AUTHOR="J. D. Case and D. Harrington and R. Presuhn and B. Wijnen",
TITLE="Message Processing and Dispatching for the Simple Network Management
Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2572,
PAGES=44,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="This document describes the Message Processing and Dispatching
for SNMP messages within the SNMP architecture [RFC2571]. It defines the
procedures for dispatching potentially multiple versions of SNMP
messages to the proper SNMP Message Processing Models, and for
dispatching PDUs to SNMP applications. This document also describes one
Message Processing Model - the SNMPv3 Message Processing Model.",
URL="http://www.rfc-editor.org/rfc/rfc2572.txt"
}

@TECHREPORT{rfc2573,
AUTHOR="D. Levi and P. Meyer and B. Stewart",
TITLE="{SNMP} Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2573,
PAGES=72,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="This memo describes five types of SNMP applications which make
use of an SNMP engine as described in [RFC2571]. The types of
application described are Command Generators, Command Responders,
Notification Originators, Notification Receivers, and Proxy Forwarders.",
URL="http://www.rfc-editor.org/rfc/rfc2573.txt"
}

@TECHREPORT{rfc2574,
AUTHOR="United States Postal Service  and B. Wijnen",
TITLE="User-based Security Model {(USM)} for version 3 of the Simple Network
Management Protocol {(SNMPv3)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2574,
PAGES=86,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="This document describes the User-based Security Model (USM)
for SNMP version 3 for use in the SNMP architecture [RFC2571]. It
defines the Elements of Procedure for providing SNMP message level
security. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this Security
Model.",
URL="http://www.rfc-editor.org/rfc/rfc2574.txt"
}

@TECHREPORT{rfc2575,
AUTHOR="B. Wijnen and R. Presuhn and K. McCloghrie",
TITLE="View-based Access Control Model {(VACM)} for the Simple Network Management
Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2575,
PAGES=38,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="This document describes the View-based Access Control Model
for use in the SNMP architecture [RFC2571]. It defines the Elements of
Procedure for controlling access to management information. This
document also includes a MIB for remotely managing the configuration
parameters for the View-based Access Control Model.",
URL="http://www.rfc-editor.org/rfc/rfc2575.txt"
}

@TECHREPORT{rfc2577,
AUTHOR="M. Allman and S. Ostermann",
TITLE="{FTP} Security Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2577,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2577.txt"
}

@TECHREPORT{rfc2578,
AUTHOR="K. McCloghrie and D. Perkins and J. Schoenwaelder",
TITLE="Structure of Management Information Version 2 {(SMIv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2578,
PAGES=43,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined in
MIB modules. These modules are written using an adapted subset of OSI's
Abstract Syntax Notation One, ASN.1 (1988). It is the purpose of this
document, the Structure of Management Information (SMI), to define that
adapted subset, and to assign a set of associated administrative values.",
URL="http://www.rfc-editor.org/rfc/rfc2578.txt"
}

@TECHREPORT{rfc2579,
AUTHOR="K. McCloghrie and D. Perkins and J. Schoenwaelder",
TITLE="Textual Conventions for {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2579,
PAGES=26,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined in
MIB modules. These modules are written using an adapted subset of OSI's
Abstract Syntax Notation One, ASN.1 (1988), termed the Structure of
Management Information (SMI). When designing a MIB module, it is often
useful to define new types similar to those defined in the SMI. In
comparison to a type defined in the SMI, each of these new types has a
different name, a similar syntax, but a more precise semantics. These
newly defined types are termed textual conventions, and are used for the
convenience of humans reading the MIB module. It is the purpose of this
document to define the initial set of textual conventions available to
all MIB modules.",
URL="http://www.rfc-editor.org/rfc/rfc2579.txt"
}

@TECHREPORT{rfc2580,
AUTHOR="K. McCloghrie and D. Perkins and J. Schoenwaelder",
TITLE="Conformance Statements for {SMIv2}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2580,
PAGES=29,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined in
MIB modules. These modules are written using an adapted subset of OSI's
Abstract Syntax Notation One, ASN.1 (1988), termed the Structure of
Management Information (SMI). It may be useful to define the acceptable
lower-bounds of implementation, along with the actual level of
implementation achieved. It is the purpose of this document to define
the notation used for these purposes.",
URL="http://www.rfc-editor.org/rfc/rfc2580.txt"
}

@TECHREPORT{rfc2581,
AUTHOR="M. Allman and V. Paxson and W. Richard Stevens",
TITLE="{TCP} Congestion Control",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2581,
PAGES=14,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2581.txt"
}

@TECHREPORT{rfc2582,
AUTHOR="S. Floyd and T. Henderson",
TITLE="The {NewReno} Modification to {TCP's} Fast Recovery Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2582,
PAGES=12,
DAYS=15,
MONTH=apr,
YEAR=1999,
ABSTRACT={RFC 2001 documents the following four intertwined TCP
congestion control algorithms: Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery. RFC 2581 explicitly allows certain
modifications of these algorithms, including modifications that use the
TCP Selective Acknowledgement (SACK) option, and 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.},
URL="http://www.rfc-editor.org/rfc/rfc2582.txt"
}

@TECHREPORT{rfc2583,
AUTHOR="R. Carlson and L. Winkler",
TITLE="Guidelines for Next Hop Client {(NHC)} Developers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2583,
PAGES=9,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2583.txt"
}

@TECHREPORT{rfc2584,
AUTHOR="B. Clouston and B. W. Moore",
TITLE="Definitions of Managed Objects for {APPN/HPR} in {IP} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2584,
PAGES=21,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for 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.",
URL="http://www.rfc-editor.org/rfc/rfc2584.txt"
}

@TECHREPORT{rfc2585,
AUTHOR="R. Housley and P. Hoffman",
TITLE="Internet {X.509} Public Key Infrastructure Operational Protocols: {FTP} and
{HTTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2585,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2585.txt"
}

@TECHREPORT{rfc2586,
AUTHOR="J. Salsman and H. Alvestrand",
TITLE="The {Audio/L16} {MIME} content type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2586,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="This document defines the audio/L16 MIME type, a reasonable
quality audio format for use in Internet applications. Possible
application areas include E-mail, Web served content, file upload in Web
forms, and more.",
URL="http://www.rfc-editor.org/rfc/rfc2586.txt"
}

@TECHREPORT{rfc2587,
AUTHOR="S. Boeyen and T. Howes and P. Richard",
TITLE="Internet {X.509} Public Key Infrastructure {LDAPv2} Schema",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2587,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2587.txt"
}

@TECHREPORT{rfc2588,
AUTHOR="R. Finlayson",
TITLE="{IP} Multicast and Firewalls",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2588,
PAGES=12,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="Many organizations use a firewall computer that acts as a
security gateway between the public Internet and their private, internal
'intranet'. In this document, we discuss the issues surrounding the
traversal of IP multicast traffic across a firewall, and describe
possible ways in which a firewall can implement and control this
traversal. We also explain why some firewall mechanisms - such as SOCKS
- that were designed specifically for unicast traffic, are less
appropriate for multicast. This document is the product of the MBONE
Deployment Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2588.txt"
}

@TECHREPORT{rfc2589,
AUTHOR="Y. Yaacovi and M. Wahl and T. Genovese",
TITLE="Lightweight Directory Access Protocol (v3): Extensions for Dynamic
Directory Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2589,
PAGES=12,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="This document defines the requirements for dynamic directory
services and specifies the format of request and response extended
operations for supporting client-server interoperation in a dynamic
directories environment.",
URL="http://www.rfc-editor.org/rfc/rfc2589.txt"
}

@TECHREPORT{rfc2590,
AUTHOR="A. Conta and A. Malis and M. E. Mueller",
TITLE="Transmission of {IPv6} Packets over Frame Relay Networks Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2590,
PAGES=19,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="This memo describes mechanisms for the transmission of IPv6
packets over Frame Relay networks.",
URL="http://www.rfc-editor.org/rfc/rfc2590.txt"
}

@TECHREPORT{rfc2591,
AUTHOR="D. Levi and J. Schoenwaelder",
TITLE="Definitions of Managed Objects for Scheduling Management Operations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2591,
PAGES=25,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes a set of managed objects that are
used to schedule management operations periodically or at specified
dates and times. This document is a product of the Distributed
Management Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2591.txt"
}

@TECHREPORT{rfc2592,
AUTHOR="D. Levi and J. Schoenwaelder",
TITLE="Definitions of Managed Objects for the Delegation of Management Script",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2592,
PAGES=53,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes a set of managed objects that
allow the delegation of management scripts to distributed managers. This
document is the product of the Distributed Management Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2592.txt"
}

@TECHREPORT{rfc2593,
AUTHOR="J. Schoenwaelder and Juergen Quittek",
TITLE="Script {MIB} Extensibility Protocol Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2593,
PAGES=22,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2593.txt"
}

@TECHREPORT{rfc2594,
AUTHOR="H. Hazewinkel and C. Kalbfleisch and J. Schoenwaelder",
TITLE="Definitions of Managed Objects for {WWW} Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2594,
PAGES=43,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
Community. In particular it describes a set of objects for managing
World Wide Web (WWW) services.",
URL="http://www.rfc-editor.org/rfc/rfc2594.txt"
}

@TECHREPORT{rfc2595,
AUTHOR="C. Newman",
TITLE="Using {TLS} with {IMAP,} {POP3} and {ACAP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2595,
PAGES=15,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="The TLS protocol (formerly known as SSL) provides a way to
secure an application protocol from tampering and eavesdropping. The
option of using such security is desirable for IMAP, POP and ACAP due to
common connection eavesdropping and hijacking attacks.",
URL="http://www.rfc-editor.org/rfc/rfc2595.txt"
}

@TECHREPORT{rfc2596,
AUTHOR="M. Wahl and T. Howes",
TITLE="Use of Language Codes in {LDAP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2596,
PAGES=9,
DAYS=15,
MONTH=may,
YEAR=1999,
ABSTRACT="This document describes how language codes are 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.",
URL="http://www.rfc-editor.org/rfc/rfc2596.txt"
}

@TECHREPORT{rfc2597,
AUTHOR="J. Heinanen and F. Baker and W. Weiss and J. Wroclawski",
TITLE="Assured Forwarding {PHB} Group",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2597,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="This document defines a general use Differentiated 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.",
URL="http://www.rfc-editor.org/rfc/rfc2597.txt"
}

@TECHREPORT{rfc2598,
AUTHOR="V. Jacobson and K. Nichols and K. Poduri",
TITLE="An Expedited Forwarding {PHB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2598,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2598.txt"
}

@TECHREPORT{rfc2601,
AUTHOR="M. Davison",
TITLE="{ILMI-Based} Server Discovery for {ATMARP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2601,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2601.txt"
}

@TECHREPORT{rfc2602,
AUTHOR="M. Davison",
TITLE="{ILMI-Based} Server Discovery for {MARS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2602,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2602.txt"
}

@TECHREPORT{rfc2603,
AUTHOR="M. Davison",
TITLE="{ILMI-Based} Server Discovery for {NHRP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2603,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2603.txt"
}

@TECHREPORT{rfc2604,
AUTHOR="R. Gellens",
TITLE="Wireless Device Configuration {(OTASP/OTAPA)} via {ACAP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2604,
PAGES=29,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="This paper describes a viable and attractive means to provide
OTASP/OTAPA via IS-707, using the ACAP protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2604.txt"
}

@TECHREPORT{rfc2605,
AUTHOR="G. Mansfield and S. E. Kille",
TITLE="Directory Server Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2605,
PAGES=26,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT={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-MIB for monitoring Directory
Servers.},
URL="http://www.rfc-editor.org/rfc/rfc2605.txt"
}

@TECHREPORT{rfc2606,
AUTHOR="D. Eastlake 3rd and A. Panitz",
TITLE="Reserved Top Level {DNS} Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2606,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2606.txt"
}

@TECHREPORT{rfc2607,
AUTHOR="B. Aboba and J. Vollbrecht",
TITLE="Proxy Chaining and Policy Implementation in Roaming",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2607,
PAGES=15,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2607.txt"
}

@TECHREPORT{rfc2608,
AUTHOR="E. Guttman and C. E. Perkins and J. Veizades and M. Day",
TITLE="Service Location Protocol, Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2608,
PAGES=54,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2608.txt"
}

@TECHREPORT{rfc2609,
AUTHOR="E. Guttman and C. E. Perkins and J. Kempf",
TITLE="Service Templates and Service: Schemes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2609,
PAGES=33,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2609.txt"
}

@TECHREPORT{rfc2610,
AUTHOR="C. E. Perkins and E. Guttman",
TITLE="{DHCP} Options for Service Location Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2610,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2610.txt"
}

@TECHREPORT{rfc2611,
AUTHOR="L. Daigle and D. van Gulik and R. Iannella and P. Falstrom",
TITLE="{URN} Namespace Definition Mechanisms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2611,
PAGES=14,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT={The URN WG has defined a syntax for Uniform Resource Names
(URNs) [RFC2141], as well as some proposed mechanisms for their
resolution and use in Internet applications ([RFC2168, RFC2169]). 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 ([RFC2288]), and this document
lays out general definitions of and mechanisms for establishing URN
{"}namespaces{"}.},
URL="http://www.rfc-editor.org/rfc/rfc2611.txt"
}

@TECHREPORT{rfc2612,
AUTHOR="C. J. Adams and J. Gilchrist",
TITLE="The {CAST-256} Encryption Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2612,
PAGES=19,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="There is always a desire in the Internet community for
unencumbered encryption algorithms with a range of key sizes that can
provide security for a variety of cryptographic applications and
protocols. This document describes an existing algorithm that can be
used to satisfy this requirement. Included are a description of the
cipher and the key scheduling algorithm, the s-boxes, and a set of test
vectors.",
URL="http://www.rfc-editor.org/rfc/rfc2612.txt"
}

@TECHREPORT{rfc2613,
AUTHOR="R. Waterman and B. Lahaye and D. Romascanu and S. Waldbusser",
TITLE="Remote Network Monitoring {MIB} Extensions for Switched Networks Version
{1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2613,
PAGES=44,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring devices in switched networks environments.",
URL="http://www.rfc-editor.org/rfc/rfc2613.txt"
}

@TECHREPORT{rfc2614,
AUTHOR="J. Kempf and E. Guttman",
TITLE="An {API} for Service Location",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2614,
PAGES=91,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2614.txt"
}

@TECHREPORT{rfc2615,
AUTHOR="A. Malis and W. Simpson",
TITLE="{PPP} over {SONET/SDH}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2615,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2615.txt"
}

@TECHREPORT{rfc2616,
AUTHOR="R. Fielding and J. Gettys and J. C. Mogul and H. Frystyk and L. Masinter
and P. J. Leach and T. Berners-Lee",
TITLE="Hypertext Transfer Protocol {--} {HTTP/1.1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2616,
PAGES=176,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2616.txt"
}

@TECHREPORT{rfc2617,
AUTHOR="J. Franks and P. Hallam-Baker and J. Hostetler and S. Lawrence and P. J.
Leach and A. Luotonen and L. Stewart",
TITLE="{HTTP} Authentication: Basic and Digest Access Authentication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2617,
PAGES=34,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT={{"}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.},
URL="http://www.rfc-editor.org/rfc/rfc2617.txt"
}

@TECHREPORT{rfc2618,
AUTHOR="B. Aboba and G. Zorn",
TITLE="{RADIUS} Authentication Client {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2618,
PAGES=14,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2618.txt"
}

@TECHREPORT{rfc2619,
AUTHOR="G. Zorn and B. Aboba",
TITLE="{RADIUS} Authentication Server {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2619,
PAGES=16,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2619.txt"
}

@TECHREPORT{rfc2620,
AUTHOR="B. Aboba and G. Zorn",
TITLE="{RADIUS} Accounting Client {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2620,
PAGES=13,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2620.txt"
}

@TECHREPORT{rfc2621,
AUTHOR="G. Zorn and B. Aboba",
TITLE="{RADIUS} Accounting Server {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2621,
PAGES=15,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2621.txt"
}

@TECHREPORT{rfc2622,
AUTHOR="C. Alaettinoglu and C. Villamizar and E. Gerich and D. Kessens and D. L.
Meyer and T. Bates and D. Karrenberg and M. Terpstra",
TITLE="Routing Policy Specification Language {(RPSL)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2622,
PAGES=69,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2622.txt"
}

@TECHREPORT{rfc2623,
AUTHOR="M. Eisler",
TITLE="{NFS} Version 2 and Version 3 Security Issues and the {NFS} Protocol's Use
of {RPCSEC\\_GSS} and Kerberos {V5}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2623,
PAGES=19,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="This memorandum clarifies various security issues involving
the NFS protocol (Version 2 and Version 3 only) and then describes how
the Version 2 and Version 3 of the NFS protocol use the RPCSEC\_GSS
security flavor protocol and Kerberos V5. This memorandum is provided so
that people can write compatible implementations.",
URL="http://www.rfc-editor.org/rfc/rfc2623.txt"
}

@TECHREPORT{rfc2624,
AUTHOR="S. Shepler",
TITLE="{NFS} Version 4 Design Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2624,
PAGES=22,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2624.txt"
}

@TECHREPORT{rfc2625,
AUTHOR="M. Rajagopal and R. Bhagwat and W. Rickard",
TITLE="{IP} and {ARP} over Fibre Channel",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2625,
PAGES=63,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2625.txt"
}

@TECHREPORT{rfc2626,
AUTHOR="P. Nesser Ii",
TITLE="The Internet and the Millennium Problem (Year {2000)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2626,
PAGES=275,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2626.txt"
}

@TECHREPORT{rfc2627,
AUTHOR="D. Wallner and E. Harder and R. Agee",
TITLE="Key Management for Multicast: Issues and Architectures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2627,
PAGES=23,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2627.txt"
}

@TECHREPORT{rfc2628,
AUTHOR="V. Smyslov",
TITLE="Simple Cryptographic Program Interface (Crypto {API)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2628,
PAGES=30,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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 [IPsec], [ISAKMP], [IKE], [TLS].",
URL="http://www.rfc-editor.org/rfc/rfc2628.txt"
}

@TECHREPORT{rfc2629,
AUTHOR="M. P. Rose",
TITLE="Writing {I-Ds} and {RFCs} using {XML}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2629,
PAGES=31,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2629.txt"
}

@TECHREPORT{rfc2630,
AUTHOR="R. Housley",
TITLE="Cryptographic Message Syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2630,
PAGES=60,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="This document describes the Cryptographic Message Syntax. This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.",
URL="http://www.rfc-editor.org/rfc/rfc2630.txt"
}

@TECHREPORT{rfc2631,
AUTHOR="E. Rescorla",
TITLE="{Diffie-Hellman} Key Agreement Method",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2631,
PAGES=13,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2631.txt"
}

@TECHREPORT{rfc2632,
EDITOR="B. Ramsdell",
TITLE="{S/MIME} Version 3 Certificate Handling",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2632,
PAGES=13,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="S/MIME agents MUST meet the certificate processing
requirements documented in this document in addition to those stated in
[KEYM].",
URL="http://www.rfc-editor.org/rfc/rfc2632.txt"
}

@TECHREPORT{rfc2633,
EDITOR="B. Ramsdell",
TITLE="{S/MIME} Version 3 Message Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2633,
PAGES=32,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="This document describes a protocol for adding cryptographic
signature and encryption services to MIME data. The MIME standard
[MIME-SPEC] provides a general structure for the content type of
Internet messages and allows extensions for new content type
applications.",
URL="http://www.rfc-editor.org/rfc/rfc2633.txt"
}

@TECHREPORT{rfc2634,
EDITOR="P. Hoffman",
TITLE="Enhanced Security Services for {S/MIME}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2634,
PAGES=58,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="This document describes both the procedures and the attributes
needed for the four services. Note that some of the attributes described
in this document are quite useful in other contexts and should be
considered when extending S/MIME or other CMS applications.",
URL="http://www.rfc-editor.org/rfc/rfc2634.txt"
}

@TECHREPORT{rfc2635,
AUTHOR="S. Hambridge and A. Lunde",
TITLE="{DON'T} {SPEW} A Set of Guidelines for Mass Unsolicited Mailings and
Postings (spam*)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2635,
PAGES=18,
DAYS=15,
MONTH=jun,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2635.txt"
}

@TECHREPORT{rfc2637,
AUTHOR="K. Hamzeh and G. Pall and W. Verthein and J. Taarud and W. Little and G.
Zorn",
TITLE="{Point-to-Point} Tunneling Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2637,
PAGES=57,
DAYS=15,
MONTH=jul,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2637.txt"
}

@TECHREPORT{rfc2638,
AUTHOR="K. Nichols and V. Jacobson and L. Zhang",
TITLE="A Two-bit Differentiated Services Architecture for the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2638,
PAGES=26,
DAYS=15,
MONTH=jul,
YEAR=1999,
ABSTRACT="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 proposal. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2638.txt"
}

@TECHREPORT{rfc2639,
AUTHOR="T. Hastings and C. Manros",
TITLE="Internet Printing Protocol/1.0: Implementer's Guide",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2639,
PAGES=64,
DAYS=15,
MONTH=jul,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2639.txt"
}

@TECHREPORT{rfc2640,
AUTHOR="B. Curtin",
TITLE="Internationalization of the File Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2640,
PAGES=27,
DAYS=15,
MONTH=jul,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2640.txt"
}

@TECHREPORT{rfc2641,
AUTHOR="D. Hamilton and D. Ruffen",
TITLE="Cabletron's {VlanHello} Protocol Specification Version 4",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2641,
PAGES=17,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2641.txt"
}

@TECHREPORT{rfc2642,
AUTHOR="L. Kane",
TITLE="Cabletron's {VLS} Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2642,
PAGES=95,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2642.txt"
}

@TECHREPORT{rfc2643,
AUTHOR="D. Ruffen and T. Len and J. Yanacek",
TITLE="Cabletron's {SecureFast} {VLAN} Operational Model",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2643,
PAGES=60,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="Cabletron's SecureFast VLAN (SFVLAN) product implements a
distributed connection-oriented switching 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.",
URL="http://www.rfc-editor.org/rfc/rfc2643.txt"
}

@TECHREPORT{rfc2644,
AUTHOR="D. Senie",
TITLE="Changing the Default for Directed Broadcasts in Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2644,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="Router Requirements specifies that routers must receive and
forward directed broadcasts. It also specifies that routers MUST have an
option to disable this feature, and that this option MUST default to
permit the receiving and forwarding of directed broadcasts. While
directed broadcasts have uses, their use on the Internet backbone
appears to be comprised entirely of malicious attacks on other networks.
Changing the required default for routers would help ensure new routers
connected to the Internet do not add to the problems already present.",
URL="http://www.rfc-editor.org/rfc/rfc2644.txt"
}

@TECHREPORT{rfc2645,
AUTHOR="R. Gellens",
TITLE="{ON-DEMAND} {MAIL} {RELAY} {(ODMR)} {SMTP} with Dynamic {IP} Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2645,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2645.txt"
}

@TECHREPORT{rfc2646,
EDITOR="R. Gellens",
TITLE="The {Text/Plain} Format Parameter",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2646,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2646.txt"
}

@TECHREPORT{rfc2647,
AUTHOR="D. Newman",
TITLE="Benchmarking Terminology for Firewall Performance",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2647,
PAGES=26,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This document defines terms used in measuring the performance
of firewalls. It extends the terminology already used for benchmarking
routers and switches with definitions specific to firewalls.",
URL="http://www.rfc-editor.org/rfc/rfc2647.txt"
}

@TECHREPORT{rfc2648,
AUTHOR="R. Moats",
TITLE="A {URN} Namespace for {IETF} Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2648,
PAGES=30,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT={This document proposes the {"}ietf{"} namespace, which consists of
the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by
the IETF and published by the RFC editor and the minutes of working
groups (WG) and birds of a feather (BOF) meetings that occur during IETF
conferences.},
URL="http://www.rfc-editor.org/rfc/rfc2648.txt"
}

@TECHREPORT{rfc2649,
AUTHOR="B. Greenblatt and P. Richard",
TITLE="An {LDAP} Control and Schema for Holding Operation Signatures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2649,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2649.txt"
}

@TECHREPORT{rfc2650,
AUTHOR="D. L. Meyer and J. Schmitz and C. Orange and M. Prior and C. Alaettinoglu",
TITLE="Using {RPSL} in Practice",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2650,
PAGES=26,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2650.txt"
}

@TECHREPORT{rfc2651,
AUTHOR="J. R. Allen and M. Mealling",
TITLE="The Architecture of the Common Indexing Protocol {(CIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2651,
PAGES=19,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This document describes the CIP framework, including its
architecture and the protocol specifics of exchanging indices.",
URL="http://www.rfc-editor.org/rfc/rfc2651.txt"
}

@TECHREPORT{rfc2652,
AUTHOR="J. R. Allen and M. Mealling",
TITLE="{MIME} Object Definitions for the Common Indexing Protocol {(CIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2652,
PAGES=22,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This document describes the definitions of those objects as
well as the methods and requirements needed to define a new index type.",
URL="http://www.rfc-editor.org/rfc/rfc2652.txt"
}

@TECHREPORT{rfc2653,
AUTHOR="J. R. Allen and P. J. Leach and R. Hedberg",
TITLE="{CIP} Transport Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2653,
PAGES=11,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This document specifies three protocols for transporting CIP
requests, responses and index objects, utilizing TCP, mail, and HTTP.",
URL="http://www.rfc-editor.org/rfc/rfc2653.txt"
}

@TECHREPORT{rfc2654,
AUTHOR="R. Hedberg and B. Greenblatt and R. Moats and M. Wahl",
TITLE="A Tagged Index Object for use in the Common Indexing Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2654,
PAGES=24,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2654.txt"
}

@TECHREPORT{rfc2655,
AUTHOR="T. Hardie and M. Bowman and D. Hardy and M. Schwartz and D. Wessels",
TITLE="{CIP} Index Object Format for {SOIF} Objects",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2655,
PAGES=17,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This document describes SOIF, the Summary Object Interchange
Format, as an index object type in the context of the CIP framework.",
URL="http://www.rfc-editor.org/rfc/rfc2655.txt"
}

@TECHREPORT{rfc2656,
AUTHOR="T. Hardie",
TITLE="Registration Procedures for {SOIF} Template Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2656,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="The registration procedure described in this document is
specific to SOIF template types.",
URL="http://www.rfc-editor.org/rfc/rfc2656.txt"
}

@TECHREPORT{rfc2657,
AUTHOR="Roland Hedberg",
TITLE="{LDAPv2} Client vs. Index Mesh",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2657,
MONTH=aug,
YEAR=1999,
ABSTRACT="LDAPv2 clients as implemented according to RFC 1777 have no
notion on referral. The integration between such a client and an Index
Mesh, as defined by the Common 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.",
URL="http://www.rfc-editor.org/rfc/rfc2657.txt"
}

@TECHREPORT{rfc2658,
AUTHOR="K. McKay",
TITLE="{RTP} Payload Format for {PureVoice(tm)} Audio",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2658,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2658.txt"
}

@TECHREPORT{rfc2659,
AUTHOR="E. Rescorla and A. Schiffman",
TITLE="Security Extensions For {HTML}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2659,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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 crypto-graphic enhancements
should be applied to the message. This document describes a syntax for
binding these negotiation parameters to HTML anchors.",
URL="http://www.rfc-editor.org/rfc/rfc2659.txt"
}

@TECHREPORT{rfc2660,
AUTHOR="E. Rescorla and A. Schiffman",
TITLE="The Secure {HyperText} Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2660,
PAGES=45,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2660.txt"
}

@TECHREPORT{rfc2661,
AUTHOR="W. Townsley and A. Valencia and A. Rubens and G. Pall and G. Zorn and B.
Palter",
TITLE={Layer Two Tunneling Protocol {{"}L2TP{"}}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2661,
PAGES=80,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This document describes the Layer Two Tunneling Protocol
(L2TP). STD 51, RFC 1661 specifies multi-protocol access via PPP
[RFC1661].",
URL="http://www.rfc-editor.org/rfc/rfc2661.txt"
}

@TECHREPORT{rfc2662,
AUTHOR="G. Bathrick and F. Ly",
TITLE="Definitions of Managed Objects for the {ADSL} Lines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2662,
PAGES=115,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This document defines a standard SNMP MIB for ADSL lines based
on the ADSL 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.",
URL="http://www.rfc-editor.org/rfc/rfc2662.txt"
}

@TECHREPORT{rfc2663,
AUTHOR="P. Srisuresh and M. Holdrege",
TITLE="{IP} Network Address Translator {(NAT)} Terminology and Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2663,
PAGES=30,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2663.txt"
}

@TECHREPORT{rfc2664,
AUTHOR="R. Plzak and A. Wells and E. Krol",
TITLE={{FYI} on Questions and Answers - Answers to Commonly Asked {"}New Internet
User{"} Questions},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2664,
PAGES=11,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2664.txt"
}

@TECHREPORT{rfc2665,
AUTHOR="J. Flick and J. D. Johnson",
TITLE="Definitions of Managed Objects for the Ethernet-like Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2665,
PAGES=47,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2665.txt"
}

@TECHREPORT{rfc2666,
AUTHOR="J. Flick",
TITLE="Definitions of Object Identifiers for Identifying Ethernet Chip Sets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2666,
PAGES=18,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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 the EtherLike-MIB.",
URL="http://www.rfc-editor.org/rfc/rfc2666.txt"
}

@TECHREPORT{rfc2667,
AUTHOR="D. Thaler",
TITLE="{IP} Tunnel {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2667,
PAGES=16,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2667.txt"
}

@TECHREPORT{rfc2668,
AUTHOR="A. J. Smith and J. Flick and K. de Graaf and D. Romascanu and D. McMaster
and K. McCloghrie and S. D. Roberts",
TITLE="Definitions of Managed Objects for {IEEE} {802.3} Medium Attachment Units
{(MAUs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2668,
PAGES=56,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2668.txt"
}

@TECHREPORT{rfc2669,
EDITOR="M. St. Johns",
TITLE="{DOCSIS} Cable Device {MIB} Cable Device Management Information Base for
{DOCSIS} compliant Cable Modems and Cable Modem Termination Systems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2669,
PAGES=55,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines a basic set of managed objects for
SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable
Modem Termination Systems.",
URL="http://www.rfc-editor.org/rfc/rfc2669.txt"
}

@TECHREPORT{rfc2670,
EDITOR="M. St. Johns",
TITLE="Radio Frequency {(RF)} Interface Management Information Base for
{MCNS/DOCSIS} compliant {RF} interfaces",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2670,
PAGES=72,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines a basic set of managed objects for
SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF)
interfaces.",
URL="http://www.rfc-editor.org/rfc/rfc2670.txt"
}

@TECHREPORT{rfc2671,
AUTHOR="P. Vixie",
TITLE="Extension Mechanisms for {DNS} {(EDNS0)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2671,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This document describes backward compatible mechanisms for
allowing the protocol to grow.",
URL="http://www.rfc-editor.org/rfc/rfc2671.txt"
}

@TECHREPORT{rfc2672,
AUTHOR="M. Crawford",
TITLE="{Non-Terminal} {DNS} Name Redirection",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2672,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT={This document defines a new DNS Resource Record called
{"}DNAME{"}, which provides the capability to map an entire subtree of the
DNS name space to another domain. It differs from the CNAME record which
maps a single node of the name space.},
URL="http://www.rfc-editor.org/rfc/rfc2672.txt"
}

@TECHREPORT{rfc2673,
AUTHOR="M. Crawford",
TITLE="Binary Labels in the Domain Name System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2673,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT={This document defines a {"}Bit-String Label{"} which may appear
within domain names. This new label type compactly represents a sequence
of {"}One-Bit Labels{"} and enables resource records to be stored at any
bit-boundary in a binary-named section of the domain name tree.},
URL="http://www.rfc-editor.org/rfc/rfc2673.txt"
}

@TECHREPORT{rfc2674,
AUTHOR="E. Bell and A. J. Smith and P. Langille and A. Rijhsinghani and K.
McCloghrie",
TITLE="Definitions of Managed Objects for Bridges with Traffic Classes, Multicast
Filtering and Virtual {LAN} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2674,
PAGES=86,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular, it defines 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.",
URL="http://www.rfc-editor.org/rfc/rfc2674.txt"
}

@TECHREPORT{rfc2675,
AUTHOR="D. Borman and S. E. Deering and R. Hinden",
TITLE="{IPv6} Jumbograms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2675,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2675.txt"
}

@TECHREPORT{rfc2676,
AUTHOR="G. Apostolopoulos and S. Kama and D. Williams and R. Guerin and A. Orda and
T. Przygienda",
TITLE="{QoS} Routing Mechanisms and {OSPF} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2676,
PAGES=50,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This memo describes extensions to the OSPF protocol 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.",
URL="http://www.rfc-editor.org/rfc/rfc2676.txt"
}

@TECHREPORT{rfc2677,
AUTHOR="M. Greene and J. Cucchiara and J. Luciani",
TITLE="Definitions of Managed Objects for the {NBMA} Next Hop Resolution Protocol
{(NHRP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2677,
PAGES=67,
DAYS=15,
MONTH=aug,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects for the Next Hop
Resolution Protocol (NHRP) as defined in RFC 2332.",
URL="http://www.rfc-editor.org/rfc/rfc2677.txt"
}

@TECHREPORT{rfc2679,
AUTHOR="G. T. Almes and S. Kalidindi and M. Zekauskas",
TITLE="A One-way Delay Metric for {IPPM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2679,
PAGES=20,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This memo defines a metric for one-way delay of packets across
Internet paths.",
URL="http://www.rfc-editor.org/rfc/rfc2679.txt"
}

@TECHREPORT{rfc2680,
AUTHOR="G. T. Almes and S. Kalidindi and M. Zekauskas",
TITLE="A One-way Packet Loss Metric for {IPPM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2680,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This memo defines a metric for one-way packet loss across
Internet paths.",
URL="http://www.rfc-editor.org/rfc/rfc2680.txt"
}

@TECHREPORT{rfc2681,
AUTHOR="G. T. Almes and S. Kalidindi and M. Zekauskas",
TITLE="A Round-trip Delay Metric for {IPPM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2681,
PAGES=20,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This memo defines a metric for round-trip delay of packets
across Internet paths.",
URL="http://www.rfc-editor.org/rfc/rfc2681.txt"
}

@TECHREPORT{rfc2682,
AUTHOR="I. Widjaja and A. I. Elwalid",
TITLE="Performance Issues in {VC-Merge} Capable {ATM} {LSRs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2682,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This document investigates the impact of VC merging on the
additional buffer required for the reassembly buffers and other buffers.",
URL="http://www.rfc-editor.org/rfc/rfc2682.txt"
}

@TECHREPORT{rfc2683,
AUTHOR="B. Leiba",
TITLE="{IMAP4} Implementation Recommendations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2683,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="The IMAP4 specification [RFC-2060] describes a rich protocol
for use in building clients and 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.",
URL="http://www.rfc-editor.org/rfc/rfc2683.txt"
}

@TECHREPORT{rfc2684,
AUTHOR="D. Grossman and J. Heinanen",
TITLE="Multiprotocol Encapsulation over {ATM} Adaptation Layer 5",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2684,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This memo replaces RFC 1483. It describes two encapsulations
methods for carrying network interconnect traffic over AAL type 5 over
ATM.",
URL="http://www.rfc-editor.org/rfc/rfc2684.txt"
}

@TECHREPORT{rfc2685,
AUTHOR="B. L. Fox and B. Gleeson",
TITLE="Virtual Private Networks Identifier",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2685,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="Virtual Private IP networks may span multiple Autonomous
Systems or Service Providers. There is a requirement for the use of a
globally unique VPN identifier in order to be able to refer to a
particular VPN (see section 6.1.1 of Gleeson, Heinanen, Lin, Armitage,
Malis). This document proposes a format for a globally unique VPN
identifier.",
URL="http://www.rfc-editor.org/rfc/rfc2685.txt"
}

@TECHREPORT{rfc2686,
AUTHOR="C. Bormann",
TITLE="The {Multi-Class} Extension to {Multi-Link} {PPP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2686,
PAGES=11,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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. 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 protocol and provide a small number of
extensions to add functionality and reduce the overhead.",
URL="http://www.rfc-editor.org/rfc/rfc2686.txt"
}

@TECHREPORT{rfc2687,
AUTHOR="C. Bormann",
TITLE="{PPP} in a Real-time Oriented {HDLC-like} Framing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2687,
PAGES=13,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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. 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 protocol and its
multi-class extension and add suspend/resume in a way that is as
compatible to existing hard- and firmware as possible.",
URL="http://www.rfc-editor.org/rfc/rfc2687.txt"
}

@TECHREPORT{rfc2688,
AUTHOR="S. Jackowski and D. Putzolu and E. Crawley and B. S. Davie",
TITLE="Integrated Services Mappings for Low Speed Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2688,
PAGES=16,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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. This document defines the service mappings of the IETF
Integrated Services for low-bitrate links, specifically the controlled
load and guaranteed services. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2688.txt"
}

@TECHREPORT{rfc2689,
AUTHOR="C. Bormann",
TITLE="Providing Integrated Services over Low-bitrate Links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2689,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2689.txt"
}

@TECHREPORT{rfc2690,
AUTHOR="S. Bradner",
TITLE="A Proposal for an {MOU-Based} {ICANN} Protocol Support Organization",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2690,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This is a copy of the proposal for an MOU-based Protocol
Supporting Organization that was submitted to ICANN on April 23, 1999.",
URL="http://www.rfc-editor.org/rfc/rfc2690.txt"
}

@TECHREPORT{rfc2691,
AUTHOR="S. Bradner",
TITLE="A Memorandum of Understanding for an {ICANN} Protocol Support Organization",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2691,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2691.txt"
}

@TECHREPORT{rfc2692,
AUTHOR="C. Ellison",
TITLE="{SPKI} Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2692,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="The IETF Simple Public Key Infrastructure 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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2692.txt"
}

@TECHREPORT{rfc2693,
AUTHOR="C. Ellison and B. Frantz and B. W. Lampson and R. Rivest and B. Thomas and
T. Ylonen",
TITLE="{SPKI} Certificate Theory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2693,
PAGES=43,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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. This document gives the theory behind SPKI
certificates and ACLs without going into technical detail about those
structures or their uses.",
URL="http://www.rfc-editor.org/rfc/rfc2693.txt"
}

@TECHREPORT{rfc2694,
AUTHOR="P. Srisuresh and G. Tsirtsis and P. Akkiraju and A. Heffernan",
TITLE="{DNS} extensions to Network Address Translators {(DNS\\_ALG)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2694,
PAGES=29,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2694.txt"
}

@TECHREPORT{rfc2695,
AUTHOR="A. Chiu",
TITLE="Authentication Mechanisms for {ONC} {RPC}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2695,
PAGES=18,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2695.txt"
}

@TECHREPORT{rfc2696,
AUTHOR="C. Weider and A. Herron and A. Anantha and T. Howes",
TITLE="{LDAP} Control Extension for Simple Paged Results Manipulation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2696,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This document describes an LDAPv3 control extension for simple
paging of search results. This control extension allows a client to
control the rate at which an LDAP server returns the results of an LDAP
search operation. This control may be useful when the LDAP client has
limited resources and may not be able to process the entire result set
from a given LDAP query, or when the LDAP client is connected over a
low-bandwidth connection. Other operations on the result set are not
defined in this extension. This extension is not designed to provide
more sophisticated result set management.",
URL="http://www.rfc-editor.org/rfc/rfc2696.txt"
}

@TECHREPORT{rfc2697,
AUTHOR="J. Heinanen and R. Guerin",
TITLE="A Single Rate Three Color Marker",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2697,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This document defines a Single Rate Three Color Marker
(srTCM), which can be used as component in a Diffserv traffic
conditioner [RFC2475, RFC2474]. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2697.txt"
}

@TECHREPORT{rfc2698,
AUTHOR="J. Heinanen and R. Guerin",
TITLE="A Two Rate Three Color Marker",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2698,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2698.txt"
}

@TECHREPORT{rfc2701,
AUTHOR="G. Malkin",
TITLE="Nortel Networks Multi-link Multi-node {PPP} Bundle Discovery Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2701,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2701.txt"
}

@TECHREPORT{rfc2702,
AUTHOR="Daniel O. Awduche and J. Malcolm and J. Agogbua and M. O'Dell and J.
McManus",
TITLE="Requirements for Traffic Engineering Over {MPLS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2702,
PAGES=29,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2702.txt"
}

@TECHREPORT{rfc2703,
AUTHOR="G. Klyne",
TITLE="Protocol-independent Content Negotiation Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2703,
PAGES=20,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2703.txt"
}

@TECHREPORT{rfc2704,
AUTHOR="M. Blaze and J. Feigenbaum and J. Ioannidis and A. Keromytis",
TITLE="The {KeyNote} {Trust-Management} System Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2704,
PAGES=37,
DAYS=15,
MONTH=sep,
YEAR=1999,
ABSTRACT="This memo describes version 2 of the KeyNote trust-management
system. It specifies the syntax and semantics of KeyNote `assertions',
describes `action attribute' processing, and outlines the application
architecture into which a KeyNote implementation can be fit. The KeyNote
architecture and language are useful as building blocks for the trust
management aspects of a variety of Internet protocols and services.",
URL="http://www.rfc-editor.org/rfc/rfc2704.txt"
}

@TECHREPORT{rfc2705,
AUTHOR="M. Arango and A. Dugan and I. Elliott and C. Huitema and S. Pickett",
TITLE="Media Gateway Control Protocol {(MGCP)} Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2705,
PAGES=134,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2705.txt"
}

@TECHREPORT{rfc2706,
AUTHOR="D. Eastlake 3rd and T. Goldstein",
TITLE="{ECML} v1: Field Names for {E-Commerce}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2706,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2706.txt"
}

@TECHREPORT{rfc2707,
AUTHOR="R. Bergman and T. Hastings and S. Isaacson and H. Lewis",
TITLE="Job Monitoring {MIB} - {V1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2707,
PAGES=114,
DAYS=15,
MONTH=nov,
YEAR=1999,
ABSTRACT="This document provides a printer industry standard SNMP MIB
for (1) monitoring the status and progress of print jobs (2) obtaining
resource requirements before a job is processed, (3) monitoring resource
consumption while a job is being processed and (4) collecting resource
accounting data after the completion of a job. This MIB is intended to
be implemented (1) in a printer or (2) in 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.",
URL="http://www.rfc-editor.org/rfc/rfc2707.txt"
}

@TECHREPORT{rfc2708,
AUTHOR="R. Bergman",
TITLE="Job Submission Protocol Mapping Recommendations for the Job Monitoring
{MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2708,
PAGES=26,
DAYS=15,
MONTH=nov,
YEAR=1999,
ABSTRACT="This document defines the recommended mapping for many
currently popular Job submission protocols to objects and attributes in
the Job Monitoring MIB.",
URL="http://www.rfc-editor.org/rfc/rfc2708.txt"
}

@TECHREPORT{rfc2709,
AUTHOR="P. Srisuresh",
TITLE="Security Model with Tunnel-mode {IPsec} for {NAT} Domains",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2709,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="There are a variety of NAT flavors, as described in RFC 2663.
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.",
URL="http://www.rfc-editor.org/rfc/rfc2709.txt"
}

@TECHREPORT{rfc2710,
AUTHOR="S. E. Deering and W. Fenner and B. Haberman",
TITLE="Multicast Listener Discovery {(MLD)} for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2710,
PAGES=22,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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) message types, rather than IGMP (IP
Protocol 2) message types.",
URL="http://www.rfc-editor.org/rfc/rfc2710.txt"
}

@TECHREPORT{rfc2711,
AUTHOR="C. Partridge and A. Jackson",
TITLE="{IPv6} Router Alert Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2711,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2711.txt"
}

@TECHREPORT{rfc2712,
AUTHOR="A. Medvinsky and M. Hur",
TITLE="Addition of Kerberos Cipher Suites to Transport Layer Security {(TLS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2712,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="This document proposes the addition of new cipher suites to
the TLS protocol to 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.",
URL="http://www.rfc-editor.org/rfc/rfc2712.txt"
}

@TECHREPORT{rfc2713,
AUTHOR="V. Ryan and S. Seligman and R. M. Lee",
TITLE="Schema for Representing Java(tm) Objects in an {LDAP} Directory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2713,
PAGES=21,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2713.txt"
}

@TECHREPORT{rfc2714,
AUTHOR="V. Ryan and R. M. Lee and S. Seligman",
TITLE="Schema for Representing {CORBA} Object References in an {LDAP} Directory",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2714,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2714.txt"
}

@TECHREPORT{rfc2715,
AUTHOR="D. Thaler",
TITLE="Interoperability Rules for Multicast Routing Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2715,
PAGES=22,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2715.txt"
}

@TECHREPORT{rfc2716,
AUTHOR="B. Aboba and D. Simon",
TITLE="{PPP} {EAP} {TLS} Authentication Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2716,
PAGES=24,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2716.txt"
}

@TECHREPORT{rfc2717,
AUTHOR="R. Petke and I. King",
TITLE="Registration Procedures for {URL} Scheme Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2717,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1999,
ABSTRACT="This document defines the process by which new URL scheme
names are registered.",
URL="http://www.rfc-editor.org/rfc/rfc2717.txt"
}

@TECHREPORT{rfc2718,
AUTHOR="L. Masinter and H. Alvestrand and D. Zigmond and R. Petke",
TITLE="Guidelines for new {URL} Schemes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2718,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2718.txt"
}

@TECHREPORT{rfc2719,
AUTHOR="L. Ong and I. Rytina and M. Garcia and H. Schwarzbauer and L. Coene and H.
Lin and I. Juhasz and M. Holdrege",
TITLE="Framework Architecture for Signaling Transport",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2719,
PAGES=24,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2719.txt"
}

@TECHREPORT{rfc2720,
AUTHOR="Nevil Brownlee",
TITLE="Traffic Flow Measurement: Meter {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2720,
PAGES=55,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2720.txt"
}

@TECHREPORT{rfc2721,
AUTHOR="Nevil Brownlee",
TITLE="{RTFM:} Applicability Statement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2721,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="This document provides an overview covering all aspects of
Realtime Traffic Flow Measurement, including its area of applicability
and its limitations.",
URL="http://www.rfc-editor.org/rfc/rfc2721.txt"
}

@TECHREPORT{rfc2722,
AUTHOR="Nevil Brownlee and C. B. Mills and G. Ruth",
TITLE="Traffic Flow Measurement: Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2722,
PAGES=48,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2722.txt"
}

@TECHREPORT{rfc2723,
AUTHOR="Nevil Brownlee",
TITLE="{SRL:} A Language for Describing Traffic Flows and Specifying Actions for
Flow Groups",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2723,
PAGES=22,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2723.txt"
}

@TECHREPORT{rfc2724,
AUTHOR="S. Handelman and S. Stibler and Nevil Brownlee and G. Ruth",
TITLE="{RTFM:} New Attributes for Traffic Flow Measurement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2724,
PAGES=18,
DAYS=15,
MONTH=oct,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2724.txt"
}

@TECHREPORT{rfc2725,
AUTHOR="C. Villamizar and C. Alaettinoglu and D. L. Meyer and S. Murphy",
TITLE="Routing Policy System Security",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2725,
PAGES=41,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2725.txt"
}

@TECHREPORT{rfc2726,
AUTHOR="J. Zsako",
TITLE="{PGP} Authentication for {RIPE} Database Updates",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2726,
PAGES=11,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2726.txt"
}

@TECHREPORT{rfc2728,
AUTHOR="R. Panabaker and S. Wegerif and D. Zigmond",
TITLE="The Transmission of {IP} Over the Vertical Blanking Interval of a
Television Signal",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2728,
PAGES=23,
DAYS=15,
MONTH=nov,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2728.txt"
}

@TECHREPORT{rfc2729,
AUTHOR="P. Bagnall and R. Briscoe and A. Poppitt",
TITLE="Taxonomy of Communication Requirements for Large-scale Multicast
Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2729,
PAGES=27,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2729.txt"
}

@TECHREPORT{rfc2730,
AUTHOR="S. Hanna and B. Patel and M. Shah",
TITLE="Multicast Address Dynamic Client Allocation Protocol {(MADCAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2730,
PAGES=53,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="This document defines a protocol, Multicast Address Dynamic
Client Allocation Protocol (MADCAP), that allows hosts to request
multicast addresses from multicast address allocation servers.",
URL="http://www.rfc-editor.org/rfc/rfc2730.txt"
}

@TECHREPORT{rfc2731,
AUTHOR="J. Kunze",
TITLE="Encoding Dublin Core Metadata in {HTML}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2731,
PAGES=23,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="The Dublin Core [DC1] 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 [HTML4.0]. 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 [SWISH-E], [freeWAIS-sf2.0], [GLIMPSE],
[HARVEST], [ISEARCH], etc., and the Perl [PERL] scripts in the appendix.",
URL="http://www.rfc-editor.org/rfc/rfc2731.txt"
}

@TECHREPORT{rfc2732,
AUTHOR="R. Hinden and B. E. Carpenter and L. Masinter",
TITLE="Format for Literal {IPv6} Addresses in {URL's}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2732,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT={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. This document incudes an update to the generic syntax for
Uniform Resource Identifiers defined in RFC 2396 [URL]. It defines a
syntax for IPv6 addresses and allows the use of {"}[{"} and {"}]{"} within
a URI
explicitly for this reserved purpose.},
URL="http://www.rfc-editor.org/rfc/rfc2732.txt"
}

@TECHREPORT{rfc2733,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne",
TITLE="An {RTP} Payload Format for Generic Forward Error Correction",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2733,
PAGES=26,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2733.txt"
}

@TECHREPORT{rfc2734,
AUTHOR="P. Johansson",
TITLE="{IPv4} over {IEEE} 1394",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2734,
PAGES=29,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2734.txt"
}

@TECHREPORT{rfc2735,
AUTHOR="B. L. Fox and B. Petri",
TITLE="{NHRP} Support for Virtual Private Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2735,
PAGES=12,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc2735.txt"
}

@TECHREPORT{rfc2736,
AUTHOR="M. Handley and C. E. Perkins",
TITLE="Guidelines for Writers of {RTP} Payload Format Specifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2736,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2736.txt"
}

@TECHREPORT{rfc2737,
AUTHOR="K. McCloghrie and A. Bierman",
TITLE="Entity {MIB} (Version {2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2737,
PAGES=56,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
multiple logical and physical entities managed by a single SNMP agent.",
URL="http://www.rfc-editor.org/rfc/rfc2737.txt"
}

@TECHREPORT{rfc2738,
AUTHOR="G. Klyne",
TITLE={Corrections to {{"}A} Syntax for Describing Media Feature Sets{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2738,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT={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. 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.},
URL="http://www.rfc-editor.org/rfc/rfc2738.txt"
}

@TECHREPORT{rfc2740,
AUTHOR="R. Coltun and D. A Ferguson and J. Moy",
TITLE="{OSPF} for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2740,
PAGES=80,
DAYS=15,
MONTH=dec,
YEAR=1999,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2740.txt"
}

@TECHREPORT{rfc2576,
AUTHOR="R. Frye and D. Levi and S. Routhier and B. Wijnen",
TITLE="Coexistence between Version {1,} Version {2,} and Version 3 of the
Internet-standard Network Management Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2576,
PAGES=44,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="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 1908 and
RFC2089. This document is a product of the SNMP Version 3 Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2576.txt"
}

@TECHREPORT{rfc2599,
AUTHOR="A. DeLaCruz",
TITLE="Request for Comments Summary {RFC} Numbers {2500-2599}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2599,
PAGES=23,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
2500 through RFCs 2599. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2599.txt"
}

@TECHREPORT{rfc2600,
AUTHOR="J. F. Reynolds and R. Braden",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2600,
PAGES=31,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT={This memo is published by the RFC Editor in accordance with
Section 2.1 of {"}The Internet Standards Process -- Revision 3{"}, RFC
2026,
which specifies the rules and procedures by which all Internet standards
are set. This memo is prepared by the RFC Editor for the IESG and IAB.
Please see http://www.rfc-editor.org for later updates to this document.},
URL="http://www.rfc-editor.org/rfc/rfc2600.txt"
}

@TECHREPORT{rfc2699,
AUTHOR="S. Ginoza",
TITLE="Request for Comments Summary {RFC} Numbers {2600-2699}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2699,
PAGES=22,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
2600 through RFCs 2699. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2699.txt"
}

@TECHREPORT{rfc2727,
AUTHOR="J. Galvin",
TITLE="{IAB} and {IESG} Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2727,
PAGES=15,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. This document is a product of the Process for
Organization of Internet Standards ONgoing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2727.txt"
}

@TECHREPORT{rfc2739,
AUTHOR="T. Small and D. Hennessy and F. Dawson",
TITLE="Calendar Attributes for vCard and {LDAP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2739,
PAGES=16,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2739.txt"
}

@TECHREPORT{rfc2741,
AUTHOR="M. Daniele and B. Wijnen and M. Ellison and D. Francisco",
TITLE="Agent Extensibility {(AgentX)} Protocol Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2741,
PAGES=91,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2741.txt"
}

@TECHREPORT{rfc2742,
AUTHOR="L. Heintz and S. Gudur and M. Ellison",
TITLE="Definitions of Managed Objects for Extensible {SNMP} Agents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2742,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects managing SNMP agents that
use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB
module in a manner that is both compliant to the SMIv2, and semantically
identical to the peer SMIv1 definitions.",
URL="http://www.rfc-editor.org/rfc/rfc2742.txt"
}

@TECHREPORT{rfc2743,
AUTHOR="J. R. Linn",
TITLE="Generic Security Service Application Program Interface Version {2,} Update
1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2743,
PAGES=101,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="The Generic Security Service Application Program Interface
(GSS-API), Version 2, as defined in [RFC-2078], provides security
services to callers in a generic fashion, supportable with a range of
underlying mechanisms and technologies and hence allowing source-level
portability of applications to different environments. This
specification defines GSS-API services and primitives at a level
independent of underlying mechanism and programming language
environment, and is to be complemented by other, related specifications:
documents defining specific parameter bindings for particular language
environments documents defining token formats, protocols, and procedures
to be implemented in order to realize GSS-API services atop particular
security mechanisms This memo obsoletes [RFC-2078], 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.",
URL="http://www.rfc-editor.org/rfc/rfc2743.txt"
}

@TECHREPORT{rfc2744,
AUTHOR="J. Wray",
TITLE="Generic Security Service {API} Version 2 : C-bindings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2744,
PAGES=101,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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 [GSSAPI]. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2744.txt"
}

@TECHREPORT{rfc2745,
AUTHOR="Andreas Terzis and B. Braden and S. Vincent and L. Zhang",
TITLE="{RSVP} Diagnostic Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2745,
PAGES=23,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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. This document is a product of the
Resource Reservation Setup Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2745.txt"
}

@TECHREPORT{rfc2746,
AUTHOR="Andreas Terzis and J. Krawczyk and J. Wroclawski and L. Zhang",
TITLE="{RSVP} Operation Over {IP} Tunnels",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2746,
PAGES=25,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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. This document is a product of the Resource Reservation
Setup Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2746.txt"
}

@TECHREPORT{rfc2747,
AUTHOR="F. Baker and B. Lindell and M. Talwar",
TITLE="{RSVP} Cryptographic Authentication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2747,
PAGES=21,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="This document describes the format and use of RSVP's INTEGRITY
object to provide hop-by-hop integrity and authentication of RSVP
messages. This document is a product of the Resource Reservation Setup
Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2747.txt"
}

@TECHREPORT{rfc2748,
EDITOR="D. Durham and J. Boyle and R. Cohen",
TITLE="The {COPS} (Common Open Policy Service) Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2748,
PAGES=38,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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. This document is a product of the Resource Allocation Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2748.txt"
}

@TECHREPORT{rfc2749,
EDITOR="S. Herzog and J. Boyle and R. Cohen",
TITLE="{COPS} usage for {RSVP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2749,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="This document describes usage directives for supporting COPS
policy services in RSVP environments. This document is a product of the
Resource Allocation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2749.txt"
}

@TECHREPORT{rfc2750,
AUTHOR="S. Herzog",
TITLE="{RSVP} Extensions for Policy Control",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2750,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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 [RSVP]. These extensions
include the standard format of POLICY\_DATA objects, and a description of
RSVP's handling of policy events. This document does not advocate
particular policy control mechanisms; however, a Router/Server Policy
Protocol description for these extensions can be found in [RAP, COPS,
COPS-RSVP]. This document is a product of the Resource Allocation
Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2750.txt"
}

@TECHREPORT{rfc2751,
AUTHOR="S. Herzog",
TITLE="Signaled Preemption Priority Policy Element",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2751,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="This document describes a preemption priority policy element
for use by signaled policy based admission protocols (such as [RSVP] and
[COPS]). 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.
This document is a product of the Resource Allocation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2751.txt"
}

@TECHREPORT{rfc2752,
AUTHOR="S. Yadav and R. Yavatkar and R. Pabbati and P. Ford and T. E. Moore and S.
Herzog",
TITLE="Identity Representation for {RSVP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2752,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="This document describes the representation of identity
information in POLICY\_DATA object [POL-EXT] for 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.",
URL="http://www.rfc-editor.org/rfc/rfc2752.txt"
}

@TECHREPORT{rfc2753,
AUTHOR="R. Yavatkar and D. E. Pendarakis and R. Guerin",
TITLE="A Framework for Policy-based Admission Control",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2753,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="This document is concerned with specifying a framework for
providing policy-based control over admission control decisions. In
particular, it focuses on policy-based control over admission control
using RSVP as an example of the QoS signaling mechanism. Even though the
focus of the work is on RSVP-based admission control, the document
outlines a framework that can provide policy-based admission control in
other QoS contexts. We argue that policy-based control must be
applicable to different kinds and qualities of services offered in the
same network and our goal is to consider such extensions whenever
possible.",
URL="http://www.rfc-editor.org/rfc/rfc2753.txt"
}

@TECHREPORT{rfc2754,
AUTHOR="C. Alaettinoglu and C. Villamizar and R. Govindan",
TITLE="{RPS} {IANA} Issues",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2754,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="RPS Security requires certain RPSL objects 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.",
URL="http://www.rfc-editor.org/rfc/rfc2754.txt"
}

@TECHREPORT{rfc2755,
AUTHOR="A. Chiu and M. Eisler and B. Callaghan",
TITLE="Security Negotiation for {WebNFS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2755,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="This document describes a protocol for a WebNFS client
[RFC2054] to negotiate the desired security mechanism with a WebNFS
server [RFC2055] before the WebNFS client falls back to the MOUNT v3
protocol [RFC1813]. This document is provided so that people can write
compatible implementations.",
URL="http://www.rfc-editor.org/rfc/rfc2755.txt"
}

@TECHREPORT{rfc2756,
AUTHOR="P. Vixie and D. Wessels",
TITLE="Hyper Text Caching Protocol {(HTCP/0.0)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2756,
PAGES=15,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2756.txt"
}

@TECHREPORT{rfc2757,
AUTHOR="Gabriel E. Montenegro and S. Dawkins and M. Kojo and V. Magret and N.
Vaidya",
TITLE="Long Thin Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2757,
PAGES=46,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2757.txt"
}

@TECHREPORT{rfc2758,
AUTHOR="K. White",
TITLE="Definitions of Managed Objects for Service Level Agreements Performance
Monitoring",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2758,
PAGES=71,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2758.txt"
}

@TECHREPORT{rfc2759,
AUTHOR="G. Zorn",
TITLE="Microsoft {PPP} {CHAP} Extensions, Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2759,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=2000,
ABSTRACT="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. 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). In particular,
certain protocol fields have been deleted or reused but with different
semantics. In addition, MS-CHAP-V2 features mutual authentication. 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. This document is a product of the Point-to-Point
Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2759.txt"
}

@TECHREPORT{rfc2760,
EDITOR="M. Allman and S. Dawkins and D. Glover",
TITLE="Ongoing {TCP} Research Related to Satellites",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2760,
PAGES=46,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2760.txt"
}

@TECHREPORT{rfc2761,
AUTHOR="J. Dunn and C. Dianne Martin",
TITLE="Terminology for {ATM} Benchmarking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2761,
PAGES=32,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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). This document is a product of the Benchmarking Methodology
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2761.txt"
}

@TECHREPORT{rfc2762,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne",
TITLE="Sampling of the Group Membership in {RTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2762,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. This document is a product of the Audio/Video Transport
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2762.txt"
}

@TECHREPORT{rfc2763,
AUTHOR="N. Shen and H. Smit",
TITLE="Dynamic Hostname Exchange Mechanism for {IS-IS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2763,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. This
document is a product of the IS-IS for IP Internets Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2763.txt"
}

@TECHREPORT{rfc2764,
AUTHOR="B. Gleeson and A. Y. Lin and J. Heinanen and G. Armitage and A. Malis",
TITLE="A Framework for {IP} Based Virtual Private Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2764,
PAGES=62,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2764.txt"
}

@TECHREPORT{rfc2765,
AUTHOR="E. Nordmark",
TITLE="Stateless {IP/ICMP} Translation Algorithm {(SIIT)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2765,
PAGES=26,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT={This document specifies a transition mechanism algorithm in
addition to the mechanisms already specified in [TRANS-MECH]. 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. This document is a product of the Next Generation
Transition Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2765.txt"
}

@TECHREPORT{rfc2766,
AUTHOR="G. Tsirtsis and P. Srisuresh",
TITLE="Network Address Translation - Protocol Translation {(NAT-PT)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2766,
PAGES=21,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="This document specifies an IPv4-to-IPv6 transition mechanism,
in addition to those already specified in [TRANS]. This solution
attempts to provide transparent routing, as defined in [NAT-TERM], 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 in [NAT-TERM] and V6/V4 protocol
translation theme as described in [SIIT]. This document is a product of
the Next Generation Transition Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2766.txt"
}

@TECHREPORT{rfc2767,
AUTHOR="K. Tsuchiya and H. Higuchi and Y. Atarashi",
TITLE={Dual Stack Hosts using the {{"}Bump-In-the-Stack{"}} Technique {(BIS)}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2767,
PAGES=13,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT={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. This document is a product of the Next Generation
Transition Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2767.txt"
}

@TECHREPORT{rfc2768,
AUTHOR="B. Aiken and J. Strassner and B. E. Carpenter and I. Foster and C. A. Lynch
and J. Mambretti and R. Moore and B. Teitelbaum",
TITLE="Network Policy and Services: A Report of a Workshop on Middleware",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2768,
PAGES=29,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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\&D was
recognized, and a list of specific topics needing further work was
identified.",
URL="http://www.rfc-editor.org/rfc/rfc2768.txt"
}

@TECHREPORT{rfc2769,
AUTHOR="C. Villamizar and C. Alaettinoglu and R. Govindan and D. L. Meyer",
TITLE="Routing Policy System Replication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2769,
PAGES=42,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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 RFC addresses 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. This document is a product of the
Routing Policy System Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2769.txt"
}

@TECHREPORT{rfc2770,
AUTHOR="D. L. Meyer and P. Lothberg",
TITLE="{GLOP} Addressing in {233/8}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2770,
PAGES=5,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. [RFC2365]). This document is
a product of the MBONE Deployment Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2770.txt"
}

@TECHREPORT{rfc2771,
AUTHOR="R. Finlayson",
TITLE="An Abstract {API} for Multicast Address Allocation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2771,
PAGES=11,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT={This document describes the {"}abstract service interface{"} for
the dynamic multicast address allocation service, as seen by
applications. While it does not describe a concrete API (i.e., for a
specific programming language), it describes - in abstract terms - the
semantics of this service, including the guarantees that it makes to
applications. Additional documents (not necessarily products of the
IETF) would describe concrete APIs for this service. This document is a
product of the Multicast-Address Allocation Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2771.txt"
}

@TECHREPORT{rfc2772,
AUTHOR="R. Rockell and R. Fink",
TITLE="6Bone Backbone Routing Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2772,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. 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. This
document is a product of the Next Generation Transition Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2772.txt"
}

@TECHREPORT{rfc2773,
AUTHOR="R. Housley and P. Yee and W. Nace",
TITLE="Encryption using {KEA} and {SKIPJACK}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2773,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT={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. This document
is a product of the Common Authentication Technology Working Group of
the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2773.txt"
}

@TECHREPORT{rfc2774,
AUTHOR="H. Nielsen and P. J. Leach and S. Lawrence",
TITLE="An {HTTP} Extension Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2774,
PAGES=20,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2774.txt"
}

@TECHREPORT{rfc2775,
AUTHOR="B. E. Carpenter",
TITLE="Internet Transparency",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2775,
PAGES=18,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc2775.txt"
}

@TECHREPORT{rfc2776,
AUTHOR="M. Handley and D. Thaler and R. Kermode",
TITLE="{Multicast-Scope} Zone Announcement Protocol {(MZAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2776,
PAGES=27,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. This document is a product
of the MBONE Deployment Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2776.txt"
}

@TECHREPORT{rfc2777,
AUTHOR="D. Eastlake 3rd",
TITLE="Publicly Verifiable Nomcom Random Selection",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2777,
PAGES=16,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. This document is
a product of the Process for Organization of Internet Standards ONgoing
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2777.txt"
}

@TECHREPORT{rfc2778,
AUTHOR="M. Day and J. Rosenberg and H. Sugano",
TITLE="A Model for Presence and Instant Messaging",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2778,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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. This document is a product of the Instant Messaging and
Presence Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2778.txt"
}

@TECHREPORT{rfc2779,
AUTHOR="M. Day and S. Aggarwal and G. Mohr and J. Vincent",
TITLE="Instant Messaging / Presence Protocol Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2779,
PAGES=26,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT={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. 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. This document is a product of the Instant Messaging and
Presence Protocol Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2779.txt"
}

@TECHREPORT{rfc2780,
AUTHOR="S. Bradner and V. Paxson",
TITLE="{IANA} Allocation Guidelines For Values In the Internet Protocol and
Related Headers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2780,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="This memo provides guidance for the IANA to use in assigning
parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol
headers.",
URL="http://www.rfc-editor.org/rfc/rfc2780.txt"
}

@TECHREPORT{rfc2781,
AUTHOR="P. Hoffman and F. Yergeau",
TITLE="{UTF-16,} an encoding of {ISO} 10646",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2781,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2781.txt"
}

@TECHREPORT{rfc2782,
AUTHOR="A. Gulbrandsen and P. Vixie and L. Esibov",
TITLE="A {DNS} {RR} for specifying the location of services {(DNS} {SRV)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2782,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=2000,
ABSTRACT="This document describes a DNS RR which specifies the location
of the server(s) for a specific protocol and domain. This document is a
product of the DNS IXFR, Notification, and Dynamic Update Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2782.txt"
}

@TECHREPORT{rfc2783,
AUTHOR="J. C. Mogul and D. L. Mills and J. Brittenson and J. Stone and United
States Postal Service ",
TITLE="{Pulse-Per-Second} {API} for {UNIX-like} Operating Systems, Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2783,
PAGES=31,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2783.txt"
}

@TECHREPORT{rfc2784,
AUTHOR="D. Farinacci and T. Li and S. Hanks and D. L. Meyer and P. Traina",
TITLE="Generic Routing Encapsulation {(GRE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2784,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="This document specifies a protocol for encapsulation of an
arbitrary network layer protocol over another arbitrary network layer
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2784.txt"
}

@TECHREPORT{rfc2785,
AUTHOR="R. Zuccherato",
TITLE={Methods for Avoiding the {{"}Small-Subgroup{"}} Attacks on the
{Diffie-Hellman} Key Agreement Method for {S/MIME}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2785,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2785.txt"
}

@TECHREPORT{rfc2786,
AUTHOR="M. St. Johns",
TITLE="{Diffie-Helman} {USM} Key Management Information Base and Textual
Convention",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2786,
PAGES=20,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in the
Internet community. In particular, it defines 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 RFC 2574. In other words,
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.",
URL="http://www.rfc-editor.org/rfc/rfc2786.txt"
}

@TECHREPORT{rfc2787,
AUTHOR="B. Jewell and D. Chuang",
TITLE="Definitions of Managed Objects for the Virtual Router Redundancy Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2787,
PAGES=31,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="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).",
URL="http://www.rfc-editor.org/rfc/rfc2787.txt"
}

@TECHREPORT{rfc2788,
AUTHOR="N. Freed and S. E. Kille",
TITLE="Network Services Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2788,
PAGES=22,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="There are a wide range of networked applications for which it
is appropriate to provide SNMP monitoring of their network usage. This
includes applications using both TCP/IP and OSI networking. This
document defines a MIB which contains the elements common to the
monitoring of any network service application. This information includes
a table of all monitorable network service applications, a count of the
associations (connections) to each application, and basic information
about the parameters and status of each application-related association.
This MIB may be used on its own for any application, and for most simple
applications this will suffice. This MIB is also designed to serve as a
building block which can be used in conjunction with
application-specific monitoring and management. Two examples of this are
MIBs defining additional variables for monitoring a Message Transfer
Agent (MTA) service or a Directory Service Agent (DSA) service. It is
expected that further MIBs of this nature will be specified. This MIB
does not attempt to provide facilities for management of the host or
hosts the network service application runs on, nor does it provide
facilities for monitoring applications that provide something other than
a network service. Host resource and general application monitoring is
handled by either the Host Resources MIB or the application MIB. This
document is a product of the Mail and Directory Management Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2788.txt"
}

@TECHREPORT{rfc2789,
AUTHOR="N. Freed and S. E. Kille",
TITLE="Mail Monitoring {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2789,
PAGES=33,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. Specifically, this memo extends the basic Network Services
Monitoring MIB defined in RFC 2788 to allow monitoring of Message
Transfer Agents (MTAs). It may also be used to monitor MTA components
within gateways.",
URL="http://www.rfc-editor.org/rfc/rfc2789.txt"
}

@TECHREPORT{rfc2790,
AUTHOR="S. Waldbusser and P. Grillo",
TITLE="Host Resources {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2790,
PAGES=50,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT={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.},
URL="http://www.rfc-editor.org/rfc/rfc2790.txt"
}

@TECHREPORT{rfc2791,
AUTHOR="J. Yu",
TITLE="Scalable Routing Design Principles",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2791,
PAGES=26,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2791.txt"
}

@TECHREPORT{rfc2792,
AUTHOR="M. Blaze and J. Ioannidis and A. Keromytis",
TITLE="{DSA} and {RSA} Key and Signature Encoding for the {KeyNote} Trust
Management System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2792,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="This memo describes RSA and DSA key and signature encoding,
and binary key encoding for version 2 of the KeyNote trust-management
system.",
URL="http://www.rfc-editor.org/rfc/rfc2792.txt"
}

@TECHREPORT{rfc2793,
AUTHOR="G. Hellstrom",
TITLE="{RTP} Payload for Text Conversation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2793,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="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. Text conversation is used alone
or in connection to other conversational facilities such as video and
voice, to form multimedia conversation services. 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. This
document is a product of the Audio/Video Transport Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2793.txt"
}

@TECHREPORT{rfc2794,
AUTHOR="P. Calhoun and C. E. Perkins",
TITLE="Mobile {IP} Network Access Identifier Extension for {IPv4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2794,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=2000,
ABSTRACT="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 RFC 2290 which specifies
the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile
Node's Home Address field of this option to be zero.",
URL="http://www.rfc-editor.org/rfc/rfc2794.txt"
}

@TECHREPORT{rfc2795,
AUTHOR="S. Christey",
TITLE="The Infinite Monkey Protocol Suite {(IMPS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2795,
PAGES=20,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc2795.txt"
}

@TECHREPORT{rfc2796,
AUTHOR="T. Bates and R. Chandra and E. H. Chen",
TITLE="{BGP} Route Reflection - An Alternative to Full Mesh {IBGP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2796,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT={The Border Gateway Protocol is 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. This document describes the use and
design of a method known as {"}Route Reflection{"} to alleviate the the
need
for {"}full mesh{"} IBGP. This document is a product of the Inter-Domain
Routing Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2796.txt"
}

@TECHREPORT{rfc2797,
AUTHOR="M. Myers and X. Liu and J. Schaad and J. Weinstein",
TITLE="Certificate Management Messages over {CMS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2797,
PAGES=47,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="This document defines a Certificate Management protocol using
CMS (CMC). This protocol addresses two immediate needs within the
Internet PKI community: 1. The need for an interface to public key
certification products and services based on [CMS] and [PKCS10], and 2.
The need in [SMIMEV3] for a certificate enrollment protocol for
DSA-signed certificates with Diffie-Hellman public keys. A small number
of additional services are defined to supplement the core certificate
request service. Throughout this specification the term CMS is used to
refer to both [CMS] and [PKCS7]. 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 Syntax [CMS] that
provides a superset of the PKCS7 syntax. The term CMC refers to this
specification. This document is a product of the Public-Key
Infrastructure (X.509) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2797.txt"
}

@TECHREPORT{rfc2798,
AUTHOR="M. Smith",
TITLE="Definition of the {inetOrgPerson} {LDAP} Object Class",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2798,
PAGES=20,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="While the X.500 standards define many useful attribute types
[X520] and object classes [X521], 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.",
URL="http://www.rfc-editor.org/rfc/rfc2798.txt"
}

@TECHREPORT{rfc2799,
AUTHOR="S. Ginoza",
TITLE="Request for Comments Summary {RFC} Numbers {2700-2799}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2799,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT={Many RFCs, but not all, are Proposed Standards, Draft
Standards, or Standards. Since the status of these RFCs may change
during the standards processing, we note here only that they are on the
standards track. Please see the latest edition of {"}Internet Official
Protocol Standards{"} for the current state and status of these RFCs. In
the following, RFCs on the standards track are marked [STANDARDS-TRACK].
This RFC is a slightly annotated list of the 100 RFCs from RFC 2700
through RFCs 2799. This is a status report on these RFCs. This memo
provides information for the Internet community. It does not specify an
Internet standard of any kind. Distribution of this memo is unlimited.},
URL="http://www.rfc-editor.org/rfc/rfc2799.txt"
}

@TECHREPORT{rfc2801,
AUTHOR="D. Burdett",
TITLE="Internet Open Trading Protocol - {IOTP} Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2801,
PAGES=290,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="The Internet Open Trading Protocol (IOTP) provides an
interoperable framework for Internet commerce. It is payment system
independent and encapsulates payment systems such as SET, Secure Channel
Credit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle
cases where such merchant roles as the shopping site, the Payment
Handler, the Delivery Handler of goods or services, and the provider of
customer support are performed by different parties or by one party.
This document is a product of the Internet Open Trading Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2801.txt"
}

@TECHREPORT{rfc2802,
AUTHOR="K. Davidson and Y. Kawatsura",
TITLE="Digital Signatures for the v1.0 Internet Open Trading Protocol {(IOTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2802,
PAGES=29,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="A syntax and procedures are described for the computation and
verification of digital signatures for use within Version 1.0 of the
Internet Open Trading Protocol (IOTP). This document is a product of the
Internet Open Trading Protocol Wokring Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2802.txt"
}

@TECHREPORT{rfc2803,
AUTHOR="H. Maruyama and K. Tamura and N. Uramoto",
TITLE="Digest Values for {DOM} {(DOMHASH)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2803,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="This memo defines a clear and unambiguous definition of digest
(hash) values of the XML objects regardless of the surface string
variation of XML. This definition can be used for XML digital signature
as well efficient replication of XML objects. This document is a product
of the Internet Open Trading Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2803.txt"
}

@TECHREPORT{rfc2804,
AUTHOR="Anton Riabov and  Iesg",
TITLE="{IETF} Policy on Wiretapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2804,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT={The Internet Engineering Task Force (IETF) has been asked to
take a position on the inclusion into IETF standards-track documents of
functionality designed to facilitate wiretapping. This memo explains
what the IETF thinks the question means, why its answer is {"}no{"}, and
what that answer means. This document is a product of the Internet
Architecture Board.},
URL="http://www.rfc-editor.org/rfc/rfc2804.txt"
}

@TECHREPORT{rfc2805,
AUTHOR="N. Greene and M. Ramalho and B. Rosen",
TITLE="Media Gateway Control Protocol Architecture and Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2805,
PAGES=45,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="This document describes protocol requirements for the Media
Gateway Control Protocol between a Media Gateway Controller and a Media
Gateway. This document is a product of the Media Gateway Control Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2805.txt"
}

@TECHREPORT{rfc2806,
AUTHOR="A. Vaha-Sipila",
TITLE="{URLs} for Telephone Calls",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2806,
PAGES=21,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT={This document specifies URL (Uniform Resource Locator) schemes
{"}tel{"}, {"}fax{"} and {"}modem{"} for specifying the location of a
terminal in
the phone network and the connection types (modes of operation) that can
be used to connect to that entity. This specification covers voice calls
(normal phone calls, answering machines and voice messaging systems),
facsimile (telefax) calls and data calls, both for POTS and
digital/mobile subscribers.},
URL="http://www.rfc-editor.org/rfc/rfc2806.txt"
}

@TECHREPORT{rfc2807,
AUTHOR="J. Reagle",
TITLE="{XML} Signature Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2807,
PAGES=9,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This document lists the design principles, scope, and
requirements for the XML Digital Signature specification. It includes
requirements as they relate to the signature syntax, data model, format,
cryptographic processing, and external requirements and coordination.
This document is a product of the XML Digital Signatures Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2807.txt"
}

@TECHREPORT{rfc2808,
AUTHOR="M. Nystrom",
TITLE="The {SecurID(r)} {SASL} Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2808,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="SecurID is a hardware token card product (or software
emulation thereof) produced by RSA Security Inc., which is used for
end-user authentication. This document defines a SASL [RFC2222]
authentication mechanism using these tokens, thereby providing a means
for such tokens to be used in SASL environments. This mechanism is only
for authentication, and has no effect on the protocol encoding and is
not designed to provide integrity or confidentiality services.",
URL="http://www.rfc-editor.org/rfc/rfc2808.txt"
}

@TECHREPORT{rfc2809,
AUTHOR="B. Aboba and G. Zorn",
TITLE="Implementation of {L2TP} Compulsory Tunneling via {RADIUS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2809,
PAGES=23,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="This document discusses implementation issues arising in the
provisioning of compulsory tunneling in dial-up networks using the L2TP
protocol. This provisioning can be accomplished via the integration of
RADIUS and tunneling protocols. Implementation issues encountered with
other tunneling protocols are left to separate documents. This document
is a product of the Remote Authentication Dial-In User Service Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2809.txt"
}

@TECHREPORT{rfc2810,
AUTHOR="C. Kalt",
TITLE="Internet Relay Chat: Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2810,
PAGES=10,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="The IRC (Internet Relay Chat) protocol is for use with text
based conferencing. It has been developed since 1989 when it was
originally implemented as a mean for users on a BBS to chat amongst
themselves. First formally documented in May 1993 by RFC 1459, the
protocol has kept evolving. This document is an update describing the
architecture of the current IRC protocol and the role of its different
components. Other documents describe in detail the protocol used between
the various components defined here.",
URL="http://www.rfc-editor.org/rfc/rfc2810.txt"
}

@TECHREPORT{rfc2811,
AUTHOR="C. Kalt",
TITLE="Internet Relay Chat: Channel Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2811,
PAGES=19,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="One of the most notable characteristics of the IRC (Internet
Relay Chat) protocol is to allow for users to be grouped in forums,
called channels, providing a mean for multiple users to communicate
together. There was originally a unique type of channels, but with the
years, new types appeared either as a response to a need, or for
experimental purposes.",
URL="http://www.rfc-editor.org/rfc/rfc2811.txt"
}

@TECHREPORT{rfc2812,
AUTHOR="C. Kalt",
TITLE="Internet Relay Chat: Client Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2812,
PAGES=63,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="The IRC (Internet Relay Chat) protocol is for use with text
based conferencing; the simplest client being any socket program capable
of connecting to the server. This document defines the Client Protocol,
and assumes that the reader is familiar with the IRC Architecture.",
URL="http://www.rfc-editor.org/rfc/rfc2812.txt"
}

@TECHREPORT{rfc2813,
AUTHOR="C. Kalt",
TITLE="Internet Relay Chat: Server Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2813,
PAGES=26,
DAYS=15,
MONTH=apr,
YEAR=2000,
ABSTRACT="While based on the client-server model, the IRC (Internet
Relay Chat) protocol allows servers to connect to each other effectively
forming a network. This document defines the protocol used by servers to
talk to each other. It was originally a superset of the client protocol
but has evolved differently. First formally documented in May 1993 as
part of RFC 1459 [IRC], most of the changes brought since then can be
found in this document as development was focused on making the protocol
scale better. Better scalability has allowed existing world-wide
networks to keep growing and reach sizes which defy the old
specification.",
URL="http://www.rfc-editor.org/rfc/rfc2813.txt"
}

@TECHREPORT{rfc2814,
AUTHOR="R. Yavatkar and D. Hoffman and Y. Bernet and F. Baker and M. Speer",
TITLE="{SBM} (Subnet Bandwidth Manager): A Protocol for {RSVP-based} Admission
Control over {IEEE} 802-style networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2814,
PAGES=60,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This document describes a signaling method and protocol for
RSVP-based admission control over IEEE 802-style LANs. The protocol is
designed to work both with the current generation of IEEE 802 LANs as
well as with the recent work completed by the IEEE 802.1 committee. This
document is a product of the Integrated Services Over Specific Link
Layers Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2814.txt"
}

@TECHREPORT{rfc2815,
AUTHOR="M. Seaman and A. J. Smith and E. Crawley and J. Wroclawski",
TITLE="Integrated Service Mappings on {IEEE} 802 Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2815,
PAGES=17,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This document describes mappings of IETF Integrated Services
over LANs built from IEEE 802 network segments which may be
interconnected by IEEE 802.1D MAC Bridges (switches). It describes
parameter mappings for supporting Controlled Load and Guaranteed Service
using the inherent capabilities of relevant IEEE 802 technologies and,
in particular, 802.1D-1998 queuing features in switches. These mappings
are one component of the Integrated Services over IEEE 802 LANs
framework.",
URL="http://www.rfc-editor.org/rfc/rfc2815.txt"
}

@TECHREPORT{rfc2816,
AUTHOR="A. Ghanwani and J. Pace and V. Srinivasan and A. J. Smith and M. Seaman",
TITLE="A Framework for Integrated Services Over Shared and Switched {IEEE} 802
{LAN} Technologies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2816,
PAGES=47,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This memo describes a framework for supporting IETF Integrated
Services on shared and switched LAN infrastructure. It includes
background material on the capabilities of IEEE 802 like networks with
regard to parameters that affect Integrated Services such as access
latency, delay variation and queuing support in LAN switches. It
discusses aspects of IETF's Integrated Services model that cannot easily
be accommodated in different LAN environments. It outlines a functional
model for supporting the Resource Reservation Protocol (RSVP) in such
LAN environments. Details of extensions to RSVP for use over LANs are
described in an accompanying memo. Mappings of the various Integrated
Services onto IEEE 802 LANs are described in another memo. This document
is a product of the Integrated Services Over Specific Link Layers
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2816.txt"
}

@TECHREPORT{rfc2817,
AUTHOR="R. Khare and S. Lawrence",
TITLE="Upgrading to {TLS} Within {HTTP/1.1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2817,
PAGES=13,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT={This memo explains how to use the Upgrade mechanism in
HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP
connection. This allows unsecured and secured HTTP traffic to share the
same well known port (in this case, http: at 80 rather than https: at
443). It also enables {"}virtual hosting{"}, so a single HTTP + TLS server
can disambiguate traffic intended for several hostnames at a single IP
address. Since HTTP/1.1 defines Upgrade as a hop-by-hop mechanism, this
memo also documents the HTTP CONNECT method for establishing end-to-end
tunnels across HTTP proxies. Finally, this memo establishes new IANA
registries for public HTTP status codes, as well as public or private
Upgrade product tokens. This memo does NOT affect the current definition
of the \'https' URI scheme, which already defines a separate namespace
(http://example.org/ and https://example.org/ are not equivalent). This
document is a product of the Transport Layer Security Working Group of
the IETF},
URL="http://www.rfc-editor.org/rfc/rfc2817.txt"
}

@TECHREPORT{rfc2818,
AUTHOR="E. Rescorla",
TITLE="{HTTP} Over {TLS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2818,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This memo describes how to use TLS to secure HTTP connections
over the Internet. Current practice is to layer HTTP over SSL (the
predecessor to TLS), distinguishing secured traffic from insecure
traffic by the use of a different server port. This document documents
that practice using TLS. A companion document describes a method for
using HTTP/TLS over the same port as normal HTTP [RFC2817]. This
document is a product of the Transport Layer Security Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2818.txt"
}

@TECHREPORT{rfc2819,
AUTHOR="S. Waldbusser",
TITLE="Remote Network Monitoring Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2819,
PAGES=98,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring devices. This memo obsoletes RFC 1757. This memo extends that
specification by documenting the RMON MIB in SMIv2 format while
remaining semantically identical to the existing SMIv1-based MIB. This
document is a product of the Remote Network Monitoring Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2819.txt"
}

@TECHREPORT{rfc2820,
AUTHOR="E. Stokes and D. Byrne and B. Blakley and P. Behera",
TITLE="Access Control Requirements for {LDAP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2820,
PAGES=9,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This document describes the fundamental requirements of an
access control list (ACL) model for the Lightweight Directory
Application Protocol (LDAP) directory service. It is intended to be a
gathering place for access control requirements needed to provide
authorized access to and interoperability between directories. This
document is a product of the LDAP Extension Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2820.txt"
}

@TECHREPORT{rfc2823,
AUTHOR="J. Carlson and P. Langner and E. Hernandez-Valencia and J. Manchester",
TITLE="{PPP} over Simple Data Link {(SDL)} using {SONET/SDH} with {ATM-like}
framing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2823,
PAGES=28,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links, and
RFCs 1662 and 2615 provide a means to carry PPP over Synchronous Optical
Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. This
document extends these standards to include a new encapsulation for PPP
called Simple Data Link (SDL). SDL provides a very low overhead
alternative to HDLC-like encapsulation, and can also be used on
SONET/SDH links. This document is a product of the Point-to-Point
Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2823.txt"
}

@TECHREPORT{rfc2824,
AUTHOR="J. Lennox and Henning Schulzrinne",
TITLE="Call Processing Language Framework and Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2824,
PAGES=25,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="A large number of the services we wish to make possible for
Internet telephony require fairly elaborate combinations of signalling
operations, often in network devices, to complete. We want a simple and
standardized way to create such services to make them easier to
implement and deploy. This document describes an architectural framework
for such a mechanism, which we call a call processing language. It also
outlines requirements for such a language. This document is a product of
the IP Telephony Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2824.txt"
}

@TECHREPORT{rfc2825,
AUTHOR="Anton Riabov and L. Daigle and Witold Pedrycz",
TITLE="A Tangled Web: Issues of {I18N,} Domain Names, and the Other Internet
protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2825,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT={The goals of the work to {"}internationalize{"} Internet protocols
include providing all users of the Internet with the capability of using
their own language and its standard character set to express themselves,
write names, and to navigate the network. This impacts the domain names
visible in e-mail addresses and so many of today's URLs used to locate
information on the World Wide Web, etc. However, domain names are used
by Internet protocols that are used across national boundaries. These
services must interoperate worldwide, or we risk isolating components of
the network from each other along locale boundaries. This type of
isolation could impede not only communications among people, but
opportunities of the areas involved to participate effectively in
e-commerce, distance learning, and other activities at an international
scale, thereby retarding economic development. There are several
proposals for internationalizing domain names, however it it is still to
be determined whether any of them will ensure this interoperability and
global reach while addressing visible-name representation. Some of them
obviously do not. This document does not attempt to review any specific
proposals, as that is the work of the Internationalized Domain Name
(IDN) Working Group of the IETF, which is tasked with evaluating them in
consideration of the continued global network interoperation that is the
deserved expectation of all Internet users. This document is a statement
by the Internet Architecture Board. It is not a protocol specification,
but an attempt to clarify the range of architectural issues that the
internationalization of domain names faces. This document is a product
of the Internet Architecture Board.},
URL="http://www.rfc-editor.org/rfc/rfc2825.txt"
}

@TECHREPORT{rfc2826,
AUTHOR="Internet Activities Board",
TITLE="{IAB} Technical Comment on the Unique {DNS} Root",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2826,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="To remain a global network, the Internet requires the
existence of a globally unique public name space. The DNS name space is
a hierarchical name space derived from a single, globally unique root.
This is a technical constraint inherent in the design of the DNS.
Therefore it is not technically feasible for there to be more than one
root in the public DNS. That one root must be supported by a set of
coordinated root servers administered by a unique naming authority. Put
simply, deploying multiple public DNS roots would raise a very strong
possibility that users of different ISPs who click on the same link on a
web page could end up at different destinations, against the will of the
web page designers. This does not preclude private networks from
operating their own private name spaces, but if they wish to make use of
names uniquely defined for the global Internet, they have to fetch that
information from the global DNS naming hierarchy, and in particular from
the coordinated root servers of the global DNS naming hierarchy. This
document is a product of the Internet Architecture Board.",
URL="http://www.rfc-editor.org/rfc/rfc2826.txt"
}

@TECHREPORT{rfc2827,
AUTHOR="P. Ferguson and D. Senie",
TITLE="Network Ingress Filtering: Defeating Denial of Service Attacks which employ
{IP} Source Address Spoofing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2827,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="Recent occurrences of various Denial of Service (DoS) attacks
which have employed forged source addresses have proven to be a
troublesome issue for Internet Service Providers and the Internet
community overall. This paper discusses a simple, effective, and
straightforward method for using ingress traffic filtering to prohibit
DoS attacks which use forged IP addresses to be propagated from 'behind'
an Internet Service Provider's (ISP) aggregation point.",
URL="http://www.rfc-editor.org/rfc/rfc2827.txt"
}

@TECHREPORT{rfc2828,
AUTHOR="R. Shirey",
TITLE="Internet Security Glossary",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2828,
PAGES=212,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This Glossary (191 pages of definitions and 13 pages of
references) provides abbreviations, explanations, and recommendations
for use of information system security terminology. The intent is to
improve the comprehensibility of writing that deals with Internet
security, particularly Internet Standards documents (ISDs). To avoid
confusion, ISDs should use the same term or definition whenever the same
concept is mentioned. To improve international understanding, ISDs
should use terms in their plainest, dictionary sense. ISDs should use
terms established in standards documents and other well-founded
publications and should avoid substituting private or newly made-up
terms. ISDs should avoid terms that are proprietary or otherwise favor a
particular vendor, or that create a bias toward a particular security
technology or mechanism versus other, competing techniques that already
exist or might be developed in the future.",
URL="http://www.rfc-editor.org/rfc/rfc2828.txt"
}

@TECHREPORT{rfc2829,
AUTHOR="M. Wahl and H. Alvestrand and J. L. Hodges and R. Morgan",
TITLE="Authentication Methods for {LDAP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2829,
PAGES=16,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This document specifies particular combinations of security
mechanisms which are required and recommended in LDAP [1]
implementations. This document is a product of the LDAP Extension
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2829.txt"
}

@TECHREPORT{rfc2830,
AUTHOR="J. L. Hodges and R. Morgan and M. Wahl",
TITLE="Lightweight Directory Access Protocol (v3): Extension for Transport Layer
Security",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2830,
PAGES=12,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT={This document defines the {"}Start Transport Layer Security
(TLS) Operation{"} for LDAP [LDAPv3, TLS]. This operation provides for TLS
establishment in an LDAP association and is defined in terms of an LDAP
extended request. This document is a product of the LDAP Extension
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2830.txt"
}

@TECHREPORT{rfc2831,
AUTHOR="P. J. Leach and C. Newman",
TITLE="Using Digest Authentication as a {SASL} Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2831,
PAGES=27,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This specification defines how HTTP Digest Authentication
[Digest] can be used as a SASL [RFC 2222] mechanism for any protocol
that has a SASL profile. It is intended both as an improvement over
CRAM-MD5 [RFC 2195] and as a convenient way to support a single
authentication mechanism for web, mail, LDAP, and other protocols. This
document is a product of the LDAP Extension Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2831.txt"
}

@TECHREPORT{rfc2832,
AUTHOR="S. Hollenbeck and M. Srivastava",
TITLE="{NSI} Registry Registrar Protocol {(RRP)} Version {1.1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2832,
PAGES=39,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT={This document describes a protocol for the registration and
management of second level domain names and associated name servers in
both generic Top Level Domains (gTLDs) and country code Top Level
Domains (ccTLDs). This protocol was developed by the Network Solutions
Registry for use within the Shared Registration System and is being
published {"}as-is{"} to document the protocol implementation developed by
the Network Solutions, Inc. Registry. Internet domain name registration
typically involves three entities: a registrant who wishes to register a
domain name, a registrar who provides services to the registrant, and a
registry that provides services to the registrar while serving as the
authoritative repository of all functional information required to
resolve names registered in the registry's TLDs. This document describes
a protocol for registry-registrar communication only. The protocol does
not provide any registrant services. This document is being discussed on
the {"}rrp{"} mailing list. To join the list, send a message to
<majordomo(at)NSIRegistry.com> with the words {"}subscribe rrp{"} in the
body
of the message. There is also a web site for the mailing list archives
at <http://www.NSIRegistry.net/maillist/rrp>.},
URL="http://www.rfc-editor.org/rfc/rfc2832.txt"
}

@TECHREPORT{rfc2833,
AUTHOR="Henning Schulzrinne and S. Petrack",
TITLE="{RTP} Payload for {DTMF} Digits, Telephony Tones and Telephony Signals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2833,
PAGES=30,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This memo describes how to carry dual-tone multifrequency
(DTMF) signaling, other tone signals and telephony events in RTP
packets. This document is a product of the Audio/Video Transport Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2833.txt"
}

@TECHREPORT{rfc2834,
AUTHOR="J.-m. Pittet",
TITLE="{ARP} and {IP} Broadcast over {HIPPI-800}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2834,
PAGES=34,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT={This document specifies a method for resolving IP addresses to
ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and
for emulating IP broadcast in a logical IP subnet (LIS) as a direct
extension of HARP. This memo defines a HARP that will interoperate
between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network,
GSN). This document (when combined with RFC-2067 {"}IP over HIPPI{"})
obsoletes RFC-1374.},
URL="http://www.rfc-editor.org/rfc/rfc2834.txt"
}

@TECHREPORT{rfc2835,
AUTHOR="J.-m. Pittet",
TITLE="{IP} and {ARP} over {HIPPI-6400} {(GSN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2835,
PAGES=33,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="The ANSI T11.1 task force has standardized HIPPI-6400 also
known as Gigabyte System Network (GSN), a physical-level,
point-to-point, full-duplex, link interface for reliable,
flow-controlled, transmission of user data at 6400 Mbit/s, per
direction. A parallel copper cable interface for distances of up to 40 m
is specified in HIPPI-6400-PH Connections to a longer-distance optical
interface are standardized in HIPPI-6400-OPT. HIPPI-6400-PH defines the
encapsulation of IEEE 802.2 LLC PDUs and by implication, IP on GSN.
Another T11.1 standard describes the operation of HIPPI-6400 physical
switches HIPPI-6400-SC. T11.1 chose to leave HIPPI-6400 networking
issues largely outside the scope of their standards; this document
specifies the use of HIPPI-6400 switches as IP local area networks. This
document further specifies a method for resolving IP addresses to
HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a
logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is
the goal of this memo to define a IP and HARP that will allow
interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast
and non-broadcast capable networks.",
URL="http://www.rfc-editor.org/rfc/rfc2835.txt"
}

@TECHREPORT{rfc2836,
AUTHOR="S. Brim and B. E. Carpenter and F. Le Faucheur",
TITLE="Per Hop Behavior Identification Codes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2836,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This document defines a binary encoding to uniquely identify
PHBs and/or sets of PHBs in protocol messages. This encoding MUST be
used when such identification is required. This document is a product of
the Differentiated Services Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2836.txt"
}

@TECHREPORT{rfc2837,
AUTHOR="K. Teow",
TITLE="Definitions of Managed Objects for the Fabric Element in Fibre Channel
Standard",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2837,
PAGES=48,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="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 the objects for managing the
operations of the Fabric Element portion of the Fibre Channel Standards.
This document is a product of the IP Over Fibre Channel Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2837.txt"
}

@TECHREPORT{rfc2838,
AUTHOR="D. Zigmond and M. Vickers",
TITLE="Uniform Resource Identifiers for Television Broadcasts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2838,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="World-Wide Web browsers are starting to appear on a variety of
consumer electronic devices, such as television sets and television
set-top boxes, which are capable of receiving television programming
from either terrestrial broadcast, satellite broadcast, or cable. In
this context there is a need to reference television broadcasts using
the URI format described in [RFC 2396]. This document describes a
widely-implemented URI scheme to refer to such broadcasts. This memo
provides information for the Internet community. It does not specify an
Internet standard of any kind. Distribution of this memo is unlimited.",
URL="http://www.rfc-editor.org/rfc/rfc2838.txt"
}

@TECHREPORT{rfc2839,
AUTHOR="F. da Cruz and J. Altman",
TITLE="Internet Kermit Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2839,
PAGES=20,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This document describes a new file transfer service for the
Internet based on Telnet Protocol for option negotiation and Kermit
Protocol for file transfer and management. The Internet Kermit Service
provides access to both authenticated and anonymous users. The use of
Kermit protocol over a Telnet connection provides several advantages
over FTP, including easy traversal of firewalls, transfers over multiple
transports, and security via a combination of supported Telnet
authentication and encryption option negotiations, plus significant
functional benefits. While this document describes a new service for the
Internet, the clients for this service already exist on most platforms
in the form of Telnet clients that support the Kermit file transfer
protocol. These clients are available not only from Columbia
University's Kermit Project but also numerous third parties.",
URL="http://www.rfc-editor.org/rfc/rfc2839.txt"
}

@TECHREPORT{rfc2840,
AUTHOR="J. Altman and F. da Cruz",
TITLE="{TELNET} {KERMIT} {OPTION}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2840,
PAGES=12,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This document describes an extension to the Telnet protocol to
allow the negotiation, coordination, and use of the Kermit file transfer
and management protocol over an existing Telnet protocol connection.",
URL="http://www.rfc-editor.org/rfc/rfc2840.txt"
}

@TECHREPORT{rfc2841,
AUTHOR="P. Metzger and W. Simpson",
TITLE="{IP} Authentication using Keyed {SHA1} with Interleaved Padding {(IP-MAC)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2841,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document describes the use of keyed SHA1 with the IP
Authentication Header.",
URL="http://www.rfc-editor.org/rfc/rfc2841.txt"
}

@TECHREPORT{rfc2842,
AUTHOR="R. Chandra and J. Scudder",
TITLE="Capabilities Advertisement with {BGP-4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2842,
PAGES=5,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="Currently BGP-4 requires that when a BGP speaker receives an
OPEN message with one or more unrecognized Optional Parameters, the
speaker must terminate BGP peering. This complicates introduction of new
capabilities in BGP. This document defines new Optional Parameter,
called Capabilities, that is expected to facilitate introduction of new
capabilities in BGP by providing graceful capability advertisement
without requiring that BGP peering be terminated. This document is a
product of the Inter-Domain Routing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2842.txt"
}

@TECHREPORT{rfc2843,
AUTHOR="P. Droz and T. Przygienda",
TITLE="{Proxy-PAR}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2843,
PAGES=13,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing)
that gives ATM-attached devices the ability to interact with PNNI
devices without the necessity to fully support PAR. Proxy-PAR is
designed as a client/server interaction, of which the client side is
much simpler than the server side to allow fast implementation and
deployment. The purpose of Proxy-PAR is to allow non-ATM devices to use
the flooding mechanisms provided by PNNI for registration and automatic
discovery of services offered by ATM attached devices. The first version
of PAR primarily addresses protocols available in IPv4. But it also
contains a generic interface to access the flooding of PNNI. In
addition, Proxy-PAR-capable servers provide filtering based on VPN IDs,
IP protocols and address prefixes. This enables, for instance, routers
in a certain VPN running OSPF to find OSPF neighbors on the same subnet.
The protocol is built using a registration/query approach where devices
can register their services and query for services and protocols
registered by other clients. This document is a product of the
Internetworking Over NBMA Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2843.txt"
}

@TECHREPORT{rfc2844,
AUTHOR="T. Przygienda and P. Droz and R. W. Haas",
TITLE="{OSPF} over {ATM} and {Proxy-PAR}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2844,
PAGES=14,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This memo specifies, for OSPF implementors and users,
mechanisms describing how the protocol operates in ATM networks over PVC
and SVC meshes with the presence of Proxy-PAR. These recommendations
require no protocol changes and allow simpler, more efficient and
cost-effective network designs. It is recommended that OSPF
implementations should be able to support logical interfaces, each
consisting of one or more virtual circuits and used either as numbered
logical point-to-point links (one VC), logical NBMA networks (more than
one VC) or Point-to-MultiPoint networks (more than one VC), where a
solution simulating broadcast interfaces is not appropriate. PAR can
help distribute across the ATM cloud configuration setup and changes of
such interfaces when OSPF capable routers are (re-)configured. Proxy-PAR
can in turn be used to exchange this information between the ATM cloud
and the routers connected to it. This document is a product of the Open
Shortest Path First IGP Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2844.txt"
}

@TECHREPORT{rfc2845,
AUTHOR="P. Vixie and O. Gudmundsson and D. Eastlake 3rd and B. Wellington",
TITLE="Secret Key Transaction Authentication for {DNS} {(TSIG)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2845,
PAGES=15,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This protocol allows for transaction level authentication
using shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved recursive name server. No provision
has been made here for distributing the shared secrets; it is expected
that a network administrator will statically configure name servers and
clients using some out of band mechanism such as sneaker-net until a
secure automated mechanism for key distribution is available. This
document is a product of the DNS Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2845.txt"
}

@TECHREPORT{rfc2846,
AUTHOR="C. Allocchio",
TITLE="{GSTN} Address Element Extensions in E-mail Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2846,
PAGES=35,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="There are numerous applications where there is a need for
interaction between the GSTN addressing and Internet addressing. This
memo defines a full syntax for one specific case, where there is a need
to represent GSTN addresses within Internet e-mail addresses. This full
syntax is a superset of a minimal syntax which has been defined in [RFC
2303]. This document is a product of the Internet Fax Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2846.txt"
}

@TECHREPORT{rfc2847,
AUTHOR="M. Eisler",
TITLE="{LIPKEY} - A Low Infrastructure Public Key Mechanism Using {SPKM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2847,
PAGES=22,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This memorandum describes a method whereby one can use GSS-API
[RFC2078] to supply a secure channel between a client and server,
authenticating the client with a password, and a server with a public
key certificate. As such, it is analogous to the common low
infrastructure usage of the Transport Layer Security (TLS) protocol
[RFC2246]. The method leverages the existing Simple Public Key Mechanism
(SPKM) [RFC2025], and is specified as a separate GSS-API mechanism
(LIPKEY) layered above SPKM. This document is a product of the Common
Authentication Technology Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2847.txt"
}

@TECHREPORT{rfc2848,
AUTHOR="S. Petrack and L. Conroy",
TITLE="The {PINT} Service Protocol: Extensions to {SIP} and {SDP} for {IP} Access
to Telephone Call Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2848,
PAGES=73,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document contains the specification of the PINT Service
Protocol 1.0, which defines a protocol for invoking certain telephone
services from an IP network. These services include placing basic calls,
sending and receiving faxes, and receiving content over the telephone.
The protocol is specified as a set of enhancements and additions to the
SIP 2.0 and SDP protocols. This document is a product of the PSTN and
Internet Internetworking Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2848.txt"
}

@TECHREPORT{rfc2849,
AUTHOR="G. Good",
TITLE="The {LDAP} Data Interchange Format {(LDIF)} - Technical Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2849,
PAGES=14,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document describes a file format suitable for describing
directory information or modifications made to directory information.
The file format, known as LDIF, for LDAP Data Interchange Format, is
typically used to import and export directory information between
LDAP-based directory servers, or to describe a set of changes which are
to be applied to a directory.",
URL="http://www.rfc-editor.org/rfc/rfc2849.txt"
}

@TECHREPORT{rfc2850,
EDITOR="Internet Activities Board and B. E. Carpenter",
TITLE="Charter of the Internet Architecture Board {(IAB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2850,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=2000,
ABSTRACT="This memo documents the composition, selection, roles, and
organization of the Internet Architecture Board. It replaces RFC 1601.
This document is a product of the Internet Architecture Board.",
URL="http://www.rfc-editor.org/rfc/rfc2850.txt"
}

@TECHREPORT{rfc2851,
AUTHOR="M. Daniele and B. Haberman and S. Routhier and J. Schoenwaelder",
TITLE="Textual Conventions for Internet Network Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2851,
PAGES=16,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT={This MIB module defines textual conventions to represent
commonly used Internet network layer addressing information. The intent
is that these definitions will be imported and used in MIBs that would
otherwise define their own representations. This work is output from the
Operations and Management Area {"}IPv6MIB{"} design team.},
URL="http://www.rfc-editor.org/rfc/rfc2851.txt"
}

@TECHREPORT{rfc2852,
AUTHOR="D. Newman",
TITLE="Deliver By {SMTP} Service Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2852,
PAGES=13,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT={This memo defines a mechanism whereby a SMTP client can
request, when transmitting a message to a SMTP server, that the server
deliver the message within a prescribed period of time. A client making
such a request also specifies the message handling which is to occur if
the message cannot be delivered within the specified time period: either
the message is to be returned as undeliverable with no further
processing, or a {"}delayed{"} delivery status notification (DSN) [6] is to
be issued. This extension should not be viewed as a vehicle for
requesting {"}priority{"} processing. A receiving SMTP server may assign
whatever processing priority it wishes to a message transmitted with a
Deliver By request. A Deliver By request serves to express a message's
urgency and to provide an additional degree of determinancy in its
processing. An indication of an urgent message's status within a given
time period may be requested and will be honored. Moreover, the message
may be withdrawn if not delivered within that time period. A typical
usage of this mechanism is to prevent delivery of a message beyond some
future time of significance to the sender or recipient but not known by
the MTAs handling the message. For instance, the sender may know that
the message will be delivered as a page but does not consider the
message to be sufficiently important as to warrant paging the recipient
after business hours. In that case, the message could be marked such
that delivery attempts are not made beyond 17:00. Another common usage
arises when a sender wishes to be alerted to delivery delays. In this
case, the sender can mark a message such that if it is not delivered
within, say, 30 minutes, a {"}delayed{"} DSN is generated but delivery
attempts are nonetheless continued. In this case the sender has been
allowed to express a preference for when they would like to learn of
delivery problems.},
URL="http://www.rfc-editor.org/rfc/rfc2852.txt"
}

@TECHREPORT{rfc2853,
AUTHOR="J. Kabat and M. Upadhyay",
TITLE="Generic Security Service {API} Version 2 : Java Bindings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2853,
PAGES=96,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="The Generic Security Services Application Program Interface
(GSS-API) offers application programmers uniform access to security
services atop a variety of underlying cryptographic mechanisms. This
document specifies the Java bindings for GSS-API which is described at a
language independent conceptual level in RFC 2743. The GSS-API allows a
caller application to authenticate a principal identity, to delegate
rights to a peer, and to apply security services such as confidentiality
and integrity on a per-message basis. Examples of security mechanisms
defined for GSS-API are The Simple Public-Key GSS-API Mechanism and The
Kerberos Version 5 GSS-API Mechanism. This document is a product of the
Common Authentication Technology Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2853.txt"
}

@TECHREPORT{rfc2854,
AUTHOR="D. Connolly and L. Masinter",
TITLE="The 'text/html' Media Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2854,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT={This document summarizes the history of HTML development, and
defines the {"}text/html{"} MIME type by pointing to the relevant W3C
recommendations; it is intended to obsolete the previous IETF documents
defining HTML, including RFC 1866, RFC 1867, RFC 1980, RFC 1942 and RFC
2070, and to remove HTML from IETF Standards Track.},
URL="http://www.rfc-editor.org/rfc/rfc2854.txt"
}

@TECHREPORT{rfc2855,
AUTHOR="K. Fujisawa",
TITLE="{DHCP} for {IEEE} 1394",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2855,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="IEEE Std 1394-1995 is a standard for a High Performance Serial
Bus. Since 1394 uses a different link-layer addressing method than
conventional IEEE802/Ethernet, the usage of some fields must be
clarified to achieve interoperability. This memo describes the 1394
specific usage of some fields of DHCP messages. This document is a
product of the IP Over IEEE 1394 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2855.txt"
}

@TECHREPORT{rfc2856,
AUTHOR="A. Bierman and K. McCloghrie and R. Presuhn",
TITLE="Textual Conventions for Additional High Capacity Data Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2856,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This memo specifies new textual conventions for additional
high capacity data types, intended for SNMP implementations which
already support the Counter64 data type. The definitions contained in
this document represent a short term solution which may be deprecated in
the future.",
URL="http://www.rfc-editor.org/rfc/rfc2856.txt"
}

@TECHREPORT{rfc2857,
AUTHOR="A. Keromytis and N. Provos",
TITLE="The Use of {HMAC-RIPEMD-160-96} within {ESP} and {AH}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2857,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This memo describes the use of the HMAC algorithm [RFC 2104]
in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an
authentication mechanism within the revised IPSEC Encapsulating Security
Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC
with RIPEMD-160 provides data origin authentication and integrity
protection. Further information on the other components necessary for
ESP and AH implementations is provided by [Thayer97a]. This document is
a product of the IP Security Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2857.txt"
}

@TECHREPORT{rfc2858,
AUTHOR="T. Bates and Y. Rekhter and R. Chandra and D. Katz",
TITLE="Multiprotocol Extensions for {BGP-4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2858,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="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't
support the extensions. This document obsoletes RFC 2283.",
URL="http://www.rfc-editor.org/rfc/rfc2858.txt"
}

@TECHREPORT{rfc2859,
AUTHOR="W. Fang and N. Seddigh and Biswajit Nandy",
TITLE="A Time Sliding Window Three Colour Marker {(TSWTCM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2859,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This memo defines a Time Sliding Window Three Colour Marker
(TSWTCM), which can be used as a component in a Diff-Serv traffic
conditioner [RFC2475, RFC2474]. The marker is intended to mark packets
that will be treated by the Assured Forwarding (AF) Per Hop Behaviour
(PHB) [AFPHB] in downstream routers. The TSWTCM meters a traffic stream
and marks packets to be either green, yellow or red based on the
measured throughput relative to two specified rates: Committed Target
Rate (CTR) and Peak Target Rate (PTR).",
URL="http://www.rfc-editor.org/rfc/rfc2859.txt"
}

@TECHREPORT{rfc2860,
AUTHOR="B. E. Carpenter and F. Baker and M. Roberts",
TITLE="Memorandum of Understanding Concerning the Technical Work of the Internet
Assigned Numbers Authority",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2860,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document places on record the text of the Memorandum of
Understanding concerning the technical work of the IANA that was signed
on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN
Board on March 10, 2000.",
URL="http://www.rfc-editor.org/rfc/rfc2860.txt"
}

@TECHREPORT{rfc2861,
AUTHOR="M. Handley and J. Padhye and S. Floyd",
TITLE="{TCP} Congestion Window Validation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2861,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="TCP's congestion window controls the number of packets a TCP
flow may have in the network at any time. However, long periods when the
sender is idle or application-limited can lead to the invalidation of
the congestion window, in that the congestion window no longer reflects
current information about the state of the network. This document
describes a simple modification to TCP's congestion control algorithms
to decay the congestion window cwnd after the transition from a
sufficiently-long application-limited period, while using the slow-start
threshold ssthresh to save information about the previous value of the
congestion window. An invalid congestion window also results when the
congestion window is increased (i.e., in TCP's slow-start or congestion
avoidance phases) during application-limited periods, when the previous
value of the congestion window might never have been fully utilized. We
propose that the TCP sender should not increase the congestion window
when the TCP sender has been application-limited (and therefore has not
fully used the current congestion window). We have explored these
algorithms both with simulations and with experiments from an
implementation in FreeBSD. This document is a product of the Transport
Area Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2861.txt"
}

@TECHREPORT{rfc2862,
AUTHOR="M. Reha Civanlar and G. Cash",
TITLE="{RTP} Payload Format for {Real-Time} Pointers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2862,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document describes an RTP payload format for transporting
the coordinates of a dynamic pointer that may be used during a
presentation. Although a mouse can be used as the pointer, this payload
format is not intended and may not have all functionalities needed to
implement a general mouse event transmission mechanism. This document is
a product of the Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2862.txt"
}

@TECHREPORT{rfc2863,
AUTHOR="K. McCloghrie and F. Kastenholz",
TITLE="The Interfaces Group {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2863,
PAGES=69,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
Network Interfaces. This memo discusses the 'interfaces' group of
MIB-II, especially the experience gained from the definition of numerous
media-specific MIB modules for use in conjunction with the 'interfaces'
group for managing various sub-layers beneath the internetwork-layer. It
specifies clarifications to, and extensions of, the architectural issues
within the MIB-II model of the 'interfaces' group. This memo obsoletes
RFC 2233, the previous version of the Interfaces Group MIB. This
document is a product of the Interfaces MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2863.txt"
}

@TECHREPORT{rfc2864,
AUTHOR="K. McCloghrie and G. Hanson",
TITLE="The Inverted Stack Table Extension to the Interfaces Group {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2864,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects which provide an
inverted mapping of the interface stack table used for managing network
interfaces. This document is a product of the Interfaces MIB Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2864.txt"
}

@TECHREPORT{rfc2865,
AUTHOR="C. Rigney and S. Willens and A. Rubens and W. Simpson",
TITLE="Remote Authentication Dial In User Service {(RADIUS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2865,
PAGES=76,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="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. This document is a product of the Remote
Authentication Dial-In User Service Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2865.txt"
}

@TECHREPORT{rfc2866,
AUTHOR="C. Rigney",
TITLE="{RADIUS} Accounting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2866,
PAGES=28,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document describes a protocol for carrying accounting
information between a Network Access Server and a shared Accounting
Server. This document is a product of the Remote Authentication Dial-In
User Service Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2866.txt"
}

@TECHREPORT{rfc2867,
AUTHOR="G. Zorn and B. Aboba and D. Mitton",
TITLE="{RADIUS} Accounting Modifications for Tunnel Protocol Support",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2867,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document defines new RADIUS accounting Attributes and new
values for the existing Acct-Status-Type Attribute designed to support
the provision of compulsory tunneling in dial-up networks. This document
is a product of the Remote Authentication Dial-In User Service Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2867.txt"
}

@TECHREPORT{rfc2868,
AUTHOR="G. Zorn and D. Leifer and A. Rubens and J. Shriver and M. Holdrege and I.
Goyret",
TITLE="{RADIUS} Attributes for Tunnel Protocol Support",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2868,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document defines a set of RADIUS attributes designed to
support the provision of compulsory tunneling in dial-up networks. This
document is a product of the Remote Authentication Dial-In User Service
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2868.txt"
}

@TECHREPORT{rfc2869,
AUTHOR="C. Rigney and W. Willats and P. Calhoun",
TITLE="{RADIUS} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2869,
PAGES=47,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document describes additional attributes for carrying
authentication, authorization and accounting information between a
Network Access Server (NAS) and a shared Accounting Server using the
Remote Authentication Dial In User Service (RADIUS) protocol described
in RFC 2865 and RFC 2866. This document is a product of the Remote
Authentication Dial-In User Service Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2869.txt"
}

@TECHREPORT{rfc2870,
AUTHOR="R. Bush and D. Karrenberg and M. Kosters and R. Plzak",
TITLE="Root Name Server Operational Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2870,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="As the internet becomes increasingly critical to the world's
social and economic infrastructure, attention has rightly focused on the
correct, safe, reliable, and secure operation of the internet
infrastructure itself. The root domain name servers are seen as a
crucial part of that technical infrastructure. The primary focus of this
document is to provide guidelines for operation of the root name
servers. Other major zone server operators (gTLDs, ccTLDs, major zones)
may also find it useful. These guidelines are intended to meet the
perceived societal needs without overly prescribing technical
details.This document is a product of the Domain Name Server Operations
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2870.txt"
}

@TECHREPORT{rfc2871,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="A Framework for Telephony Routing over {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2871,
PAGES=25,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This document serves as a framework for Telephony Routing over
IP (TRIP), which supports the discovery and exchange of IP telephony
gateway routing tables between providers. The document defines the
problem of telephony routing exchange, and motivates the need for the
protocol. It presents an architectural framework for TRIP, defines
terminology, specifies the various protocol elements and their
functions, overviews the services provided by the protocol, and
discusses how it fits into the broader context of Internet telephony.
This document is a product of the IP Telephony Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2871.txt"
}

@TECHREPORT{rfc2872,
AUTHOR="Y. Bernet and R. Pabbati",
TITLE="Application and Sub Application Identity Policy Element for Use with {RSVP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2872,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="RSVP [RFC 2205] signaling messages typically include policy
data objects, which in turn contain policy elements. Policy elements may
describe user and/or application information, which may be used by RSVP
aware network elements to apply appropriate policy decisions to a
traffic flow. This memo details the usage of policy elements that
provide application information. This document is a product of the
Resource Allocation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2872.txt"
}

@TECHREPORT{rfc2873,
AUTHOR="X. Xiao and A. Hannan and V. Paxson and E. Crabbe",
TITLE="{TCP} Processing of the {IPv4} Precedence Field",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2873,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=2000,
ABSTRACT="This memo describes a conflict between TCP [RFC793] and
DiffServ [RFC2475] on the use of the three leftmost bits in the TOS
octet of an IPv4 header [RFC791]. In a network that contains
DiffServ-capable nodes, such a conflict can cause failures in
establishing TCP connections or can cause some established TCP
connections to be reset undesirably. This memo proposes a modification
to TCP for resolving the conflict. Because the IPv6 [RFC2460] traffic
class octet does not have any defined meaning except what is defined in
RFC 2474, and in particular does not define precedence or security
parameter bits, there is no conflict between TCP and DiffServ on the use
of any bits in the IPv6 traffic class octet.",
URL="http://www.rfc-editor.org/rfc/rfc2873.txt"
}

@TECHREPORT{rfc2874,
AUTHOR="M. Crawford and C. Huitema",
TITLE="{DNS} Extensions to Support {IPv6} Address Aggregation and Renumbering",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2874,
PAGES=20,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This document defines changes to the Domain Name System to
support renumberable and aggregatable IPv6 addressing. The changes
include a new resource record type to store an IPv6 address in a manner
which expedites network renumbering and updated definitions of existing
query types that return Internet addresses as part of additional section
processing. For lookups keyed on IPv6 addresses (often called reverse
lookups), this document defines a new zone structure which allows a zone
to be used without modification for parallel copies of an address space
(as for a multihomed provider or site) and across network renumbering
events. This document is a product of the IPNG Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2874.txt"
}

@TECHREPORT{rfc2875,
AUTHOR="H. Prafullchandra and J. Schaad",
TITLE="{Diffie-Hellman} {Proof-of-Possession} Algorithms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2875,
PAGES=23,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This document describes two methods for producing an integrity
check value from a Diffie-Hellman key pair. This behavior is needed for
such operations as creating the signature of a PKCS #10 certification
request. These algorithms are designed to provide a proof-of-possession
rather than general purpose signing. This document is a product of the
Public-Key Infrastructure (X.509) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2875.txt"
}

@TECHREPORT{rfc2876,
AUTHOR="J. Pawling",
TITLE="Use of the {KEA} and {SKIPJACK} Algorithms in {CMS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2876,
PAGES=13,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This document describes the conventions for using the Key
Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in
conjunction with the Cryptographic Message Syntax [CMS] enveloped-data
and encrypted-data content types. This document is the product of the
S/MIME Mail Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2876.txt"
}

@TECHREPORT{rfc2877,
AUTHOR="T. Murphy and Ron Bianchini and P. Rieth and J. Stevens",
TITLE="5250 Telnet Enhancements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2877,
PAGES=36,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This memo describes the interface to the IBM 5250 Telnet
server that allows client Telnet to request a Telnet terminal or printer
session using a specific device name. If a requested device name is not
available, a method to retry the request using a new device name is
described. Methods to request specific Telnet session settings and
auto-signon function are also described. By allowing a Telnet client to
select the device name, the 5250 Telnet server opens the door for
applications to set and/or extract useful information about the Telnet
client. Some possibilities are 1) selecting a customized device name
associated with a particular user profile name for National Language
Support or subsystem routing, 2) connecting PC and network printers as
clients and 3) auto-signon using clear-text or DES-encrypted password
exchange. Applications may need to use system API's on the AS/400 in
order to extract Telnet session settings from the device name
description. Refer to the Retrieve Device Description (QDCRDEVD) API
described in the AS/400 System API book on how to extract information
using the DEVD0600 and DEVD1100 templates. This memo describes how the
IBM 5250 Telnet server supports Work Station Function (WSF) printers
using 5250 Display Station Pass-Through. A response code is returned by
the Telnet server to indicate success or failure of the WSF printer
session. This document is a product of the Telnet TN3270 Enhancements
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2877.txt"
}

@TECHREPORT{rfc2878,
AUTHOR="M. Higashiyama and F. Baker",
TITLE="{PPP} Bridging Control Protocol {(BCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2878,
PAGES=38,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="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. This document defines the Network Control
Protocol for establishing and configuring Remote Bridging for PPP links.
This document obsoletes RFC 1638, which was based on the IEEE
802.1D-1993 MAC Bridge. This document extends that specification by
including the IEEE 802.1D-1998 MAC Bridge and IEEE 802.1Q Virtual LAN
(VLAN) standards. This document also improves the protocol in order to
support high-speed switched LANs. This document is a product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2878.txt"
}

@TECHREPORT{rfc2879,
AUTHOR="G. Klyne and L. McIntyre",
TITLE="Content Feature Schema for Internet Fax {(V2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2879,
PAGES=58,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This document defines a content media feature schema for
Internet fax. It is a profile of the media feature registration
mechanisms for use in performing capability identification between
extended Internet fax systems. It replaces and updates the feature
schema defined in RFC 2531. This document is a product of the Internet
Fax Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2879.txt"
}

@TECHREPORT{rfc2880,
AUTHOR="L. McIntyre and G. Klyne",
TITLE="Internet Fax {T.30} Feature Mapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2880,
PAGES=37,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT={This document describes how to map Group 3 fax capability
identification bits, described in ITU T.30, into the Internet fax
feature schema described in {"}Content feature schema for Internet fax{"}.
This is a companion to the fax feature schema document, which itself
defines a profile of the media feature registration mechanisms, for use
in performing capability identification between extended Internet fax
systems. This document is a product of the Internet Fax Working Group of
the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2880.txt"
}

@TECHREPORT{rfc2881,
AUTHOR="D. Mitton and M. Beadles",
TITLE="Network Access Server Requirements Next Generation {(NASREQNG)} {NAS} Model",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2881,
PAGES=20,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This document describes the terminology and gives a model of
typical Network Access Server (NAS). The purpose of this effort is to
set the reference space for describing and evaluating NAS service
protocols, such as RADIUS (RFCs 2865, 2866) and follow-on efforts like
AAA Working Group, and the Diameter protocol. These are protocols for
carrying user service information for authentication, authorization,
accounting, and auditing, between a Network Access Server which desires
to authenticate its incoming calls and a shared authentication server.",
URL="http://www.rfc-editor.org/rfc/rfc2881.txt"
}

@TECHREPORT{rfc2882,
AUTHOR="D. Mitton",
TITLE="Network Access Servers Requirements: Extended {RADIUS} Practices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2882,
PAGES=16,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This document describes current practices implemented in NAS
products that go beyond the scope of the RADIUS RFCs 2138, 2139. The
purpose of this effort is to give examples that show the need for
addressing and standardizing these types of ad-hoc functions. Since many
of these features require a matching server support component, the
ability to deploy and manage interoperable NAS and AAA server products
is severely hindered. These practices are documented here to show
functions that are obviously desired in developing future AAA protocols
for NAS deployment. This document is a product of the Network Access
Server Requirements Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2882.txt"
}

@TECHREPORT{rfc2883,
AUTHOR="S. Floyd and J. Mahdavi and M. Mathis and M. Podolsky",
TITLE="An Extension to the Selective Acknowledgement {(SACK)} Option for {TCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2883,
PAGES=17,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This note defines an extension of the Selective
Acknowledgement (SACK) Option [RFC2018] for TCP. RFC 2018 specified the
use of the SACK option for acknowledging out-of-sequence data not
covered by TCP's cumulative acknowledgement field. This note extends RFC
2018 by specifying the use of the SACK option for acknowledging
duplicate packets. This note suggests that when duplicate packets are
received, the first block of the SACK option field can be used to report
the sequence numbers of the packet that triggered the acknowledgement.
This extension to the SACK option allows the TCP sender to infer the
order of packets received at the receiver, allowing the sender to infer
when it has unnecessarily retransmitted a packet. A TCP sender could
then use this information for more robust operation in an environment of
reordered packets [BPS99], ACK loss, packet replication, and/or early
retransmit timeouts. This document is a product of the Transportrea
Working Group Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2883.txt"
}

@TECHREPORT{rfc2884,
AUTHOR="J. Hadi Salim and United States Postal Service ",
TITLE="Performance Evaluation of Explicit Congestion Notification {(ECN)} in {IP}
Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2884,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=2000,
ABSTRACT="This memo presents a performance study of the Explicit
Congestion Notification (ECN) mechanism in the TCP/IP protocol using our
implementation on the Linux Operating System. ECN is an end-to-end
congestion avoidance mechanism proposed by S. Floyd and incorporated
into RFC 2481. We study the behavior of ECN for both bulk and
transactional transfers. Our experiments show that there is improvement
in throughput over NON ECN (TCP employing any of Reno, SACK/FACK or
NewReno congestion control) in the case of bulk transfers and
substantial improvement for transactional transfers. A more complete pdf
version of this document is available at:
http://www7.nortel.com:8080/CTL/ecnperf.pdf This memo in its current
revision is missing a lot of the visual representations and experimental
results found in the pdf version.",
URL="http://www.rfc-editor.org/rfc/rfc2884.txt"
}

@TECHREPORT{rfc2885,
AUTHOR="F. Cuervo and N. Greene and C. Huitema and A. Rayhan and B. Rosen and J.
Segers",
TITLE="Megaco Protocol version {0.8}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2885,
PAGES=170,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This document is common text with Recommendation H.248 as
redetermined in Geneva, February 2000. It must be read in conjunction
with the Megaco Errata, RFC 2886. A merged document presenting the
Megaco protocol with the Errata incorporated will be available shortly.
The protocol presented in this document meets the requirements for a
media gateway control protocol as presented in RFC 2805.",
URL="http://www.rfc-editor.org/rfc/rfc2885.txt"
}

@TECHREPORT{rfc2886,
AUTHOR="T. Taylor",
TITLE="Megaco Errata",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2886,
PAGES=21,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This document records the errors found in the Megaco/H.248
protocol document, along with the changes proposed in the text of that
document to resolve them. This document is a product of the Media
Gateway Control Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2886.txt"
}

@TECHREPORT{rfc2887,
AUTHOR="M. Handley and S. Floyd and B. Whetten and R. Kermode and L. Vicisano and
M. Luby",
TITLE="The Reliable Multicast Design Space for Bulk Data Transfer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2887,
PAGES=22,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="The design space for reliable multicast is rich, with many
possible solutions having been devised. However, application
requirements serve to constrain this design space to a relatively small
solution space. This document provides an overview of the design space
and the ways in which application constraints affect possible solutions.
This document is a product of the Reliable Multicast Transport Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2887.txt"
}

@TECHREPORT{rfc2888,
AUTHOR="P. Srisuresh",
TITLE="Secure Remote Access with {L2TP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2888,
PAGES=19,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="L2TP protocol is a virtual extension of PPP across IP network
infrastructure. L2TP makes possible for an access concentrator (LAC) to
be near remote clients, while allowing PPP termination server (LNS) to
be located in enterprise premises. L2TP allows an enterprise to retain
control of RADIUS data base, which is used to control Authentication,
Authorization and Accountability (AAA) of dial-in users. The objective
of this document is to extend security characteristics of IPsec to
remote access users, as they dial-in through the Internet. This is
accomplished without creating new protocols and using the existing
practices of Remote Access and IPsec. Specifically, the document
proposes three new RADIUS parameters for use by the LNS node, acting as
Secure Remote Access Server (SRAS) to mandate network level security
between remote clients and the enterprise. The document also discusses
limitations of the approach.",
URL="http://www.rfc-editor.org/rfc/rfc2888.txt"
}

@TECHREPORT{rfc2889,
AUTHOR="R. Mandeville and J. Perser",
TITLE="Benchmarking Methodology for {LAN} Switching Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2889,
PAGES=35,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT={This document is intended to provide methodology for the
benchmarking of local area network (LAN) switching devices. It extends
the methodology already defined for benchmarking network interconnecting
devices in RFC 2544 to switching devices. This RFC primarily deals with
devices which switch frames at the Medium Access Control (MAC) layer. It
provides a methodology for benchmarking switching devices, forwarding
performance, congestion control, latency, address handling and
filtering. In addition to defining the tests, this document also
describes specific formats for reporting the results of the tests. A
previous document, {"}Benchmarking Terminology for LAN Switching
Devices{"},
defined many of the terms that are used in this document. The
terminology document SHOULD be consulted before attempting to make use
of this document. This document is a product of the Benchmarking
Methodology Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2889.txt"
}

@TECHREPORT{rfc2890,
AUTHOR="G. Dommety",
TITLE="Key and Sequence Number Extensions to {GRE}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2890,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="GRE (Generic Routing Encapsulation) specifies a protocol for
encapsulation of an arbitrary protocol over another arbitrary network
layer protocol. This document describes extensions by which two fields,
Key and Sequence Number, can be optionally carried in the GRE Header.",
URL="http://www.rfc-editor.org/rfc/rfc2890.txt"
}

@TECHREPORT{rfc2891,
AUTHOR="T. Howes and M. Wahl and A. Anantha",
TITLE="{LDAP} Control Extension for Server Side Sorting of Search Results",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2891,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This document describes two LDAPv3 control extensions for
server side sorting of search results. These controls allows a client to
specify the attribute types and matching rules a server should use when
returning the results to an LDAP search request. The controls may be
useful when the LDAP client has limited functionality or for some other
reason cannot sort the results but still needs them sorted. Other
permissible controls on search operations are not defined in this
extension. The sort controls allow a server to return a result code for
the sorting of the results that is independent of the result code
returned for the search operation. This document is a product of the
LDAP Extension Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2891.txt"
}

@TECHREPORT{rfc2892,
AUTHOR="D. Tsiang and G. Suwala",
TITLE="The Cisco {SRP} {MAC} Layer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2892,
PAGES=52,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT={This document specifies the MAC layer protocol, {"}Spatial Reuse
Protocol{"} (SRP) for use with ring based media. This is a second version
of the protocol (V2). This document defines the terminology used with
SRP, packet formats, the protocol format, protocol operation and
associated protocol finite state machines.},
URL="http://www.rfc-editor.org/rfc/rfc2892.txt"
}

@TECHREPORT{rfc2893,
AUTHOR="R. Gilligan and E. Nordmark",
TITLE="Transition Mechanisms for {IPv6} Hosts and Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2893,
PAGES=29,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="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. This document obsoletes RFC
1933. This document is a product of the Next Generation Transition
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2893.txt"
}

@TECHREPORT{rfc2894,
AUTHOR="M. Crawford",
TITLE="Router Renumbering for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2894,
PAGES=32,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT={IPv6 Neighbor Discovery and Address Autoconfiguration
conveniently make initial assignments of address prefixes to hosts.
Aside from the problem of connection survival across a renumbering
event, these two mechanisms also simplify the reconfiguration of hosts
when the set of valid prefixes changes. This document defines a
mechanism called Router Renumbering ({"}RR{"}) which allows address
prefixes
on routers to be configured and reconfigured almost as easily as the
combination of Neighbor Discovery and Address Autoconfiguration works
for hosts. It provides a means for a network manager to make updates to
the prefixes used by and advertised by IPv6 routers throughout a site.
This document is a product of the IPNG Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2894.txt"
}

@TECHREPORT{rfc2895,
AUTHOR="A. Bierman and C. Bucci and R. Iddon",
TITLE="Remote Network Monitoring {MIB} Protocol Identifier Reference",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2895,
PAGES=42,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This memo defines a notation describing protocol layers in a
protocol encapsulation, specifically for use in encoding INDEX values
for the protocolDirTable, found in the RMON-2 MIB (Remote Network
Monitoring Management Information Base). The definitions for the
standard protocol directory base layer identifiers are also included.
The first version of the RMON Protocol Identifiers Document has been
split into a standards-track Reference portion (this document), and an
Informational document. The RMON Protocol Identifier Macros document now
contains the non-normative portion of that specification. This document
obsoletes RFC 2074.",
URL="http://www.rfc-editor.org/rfc/rfc2895.txt"
}

@TECHREPORT{rfc2896,
AUTHOR="A. Bierman and C. Bucci and R. Iddon",
TITLE="Remote Network Monitoring {MIB} Protocol Identifier Macros",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2896,
PAGES=84,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT={This memo contains various protocol identifier examples, which
can be used to produce valid protocolDirTable INDEX encodings, as
defined by the Remote Network Monitoring MIB (Management Information
Base) Version 2 and the RMON Protocol Identifier Reference. This
document contains protocol identifier macros for well-known protocols. A
conformant implementation of the RMON-2 MIB can be accomplished without
the use of these protocol identifiers, and accordingly, this document
does not specify any IETF standard. It is published to encourage better
interoperability between RMON-2 agent implementations, by providing a
great deal of RMON related protocol information in one document. The
first version of the RMON Protocol Identifiers Document has been split
into a standards-track Reference portion, and an {"}RMON Protocol
Identifier Macros{"}, document (this document) which contains the
non-normative portion of that specification. This document is product of
the Remote Network Monitoring Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2896.txt"
}

@TECHREPORT{rfc2897,
AUTHOR="D. Cromwell",
TITLE="Proposal for an {MGCP} Advanced Audio Package",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2897,
PAGES=34,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This document is a proposal to add a new event/signal package
to the MGCP (Media Gateway Control Protocol) protocol to control an ARF
(Audio Resource Function) which may reside on a Media Gateway or
specialized Audio Server. This event package provides support for the
standard IVR (Interactive Voice Response) operations of
PlayAnnouncement, PlayCollect, and PlayRecord. It supports direct
references to simple audio as well as indirect references to simple and
complex audio. It provides audio variables, control of audio
interruptibility, digit buffer control, special key sequences, and
support for reprompting during data collection. It also provides an
arbitrary number of user defined qualifiers to be used in resolving
complex audio structures. For example, the user could define qualifiers
for any or all of the following: language, accent, audio file format,
gender, speaker, or customer.",
URL="http://www.rfc-editor.org/rfc/rfc2897.txt"
}

@TECHREPORT{rfc2898,
AUTHOR="B. Kaliski",
TITLE="{PKCS} {#5:} {Password-Based} Cryptography Specification Version {2.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2898,
PAGES=34,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This memo represents a republication of PKCS #5 v2.0 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process. The body of this
document, except for the security considerations section, is taken
directly from that specification. This document provides recommendations
for the implementation of password-based cryptography, covering key
derivation functions, encryption schemes, message-authentication
schemes, and ASN.1 syntax identifying the techniques. The
recommendations are intended for general application within computer and
communications systems, and as such include a fair amount of
flexibility. They are particularly intended for the protection of
sensitive information such as private keys, as in PKCS #8. It is
expected that application standards and implementation profiles based on
these specifications may include additional constraints. Other
cryptographic techniques based on passwords, such as password- based key
entity authentication and key establishment protocols are outside the
scope of this document. Guidelines for the selection of passwords are
also outside the scope.",
URL="http://www.rfc-editor.org/rfc/rfc2898.txt"
}

@TECHREPORT{rfc2901,
AUTHOR="Z. Wenzel and J. Klensin and R. Bush and S. Huter",
TITLE="Guide to Administrative Procedures of the Internet Infrastructure",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2901,
PAGES=31,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This document describes the administrative procedures for
networks seeking to connect to the global Internet. This includes the
steps and operations necessary for address space allocation and
registration, routing database registration, and domain name
registration. The document also contains information about the required
forms and how to obtain them.",
URL="http://www.rfc-editor.org/rfc/rfc2901.txt"
}

@TECHREPORT{rfc2902,
AUTHOR="S. E. Deering and S. Hares and C. E. Perkins and R. Perlman",
TITLE="Overview of the 1998 {IAB} Routing Workshop",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2902,
PAGES=16,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This document is an overview of a Routing workshop held by the
Internet Architecture Board (IAB) during March 25-27, 1998. The major
points of discussion are listed, along with some conclusions and action
items for many of the points of discussion.",
URL="http://www.rfc-editor.org/rfc/rfc2902.txt"
}

@TECHREPORT{rfc2903,
AUTHOR="Cees {de Laat} and G. Gross and L. Gommans and J. Vollbrecht and D. Spence",
TITLE="Generic {AAA} Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2903,
PAGES=26,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This memo proposes an Authentication, Authorization,
Accounting (AAA) architecture that would incorporate a generic AAA
server along with an application interface to a set of Application
Specific Modules that could perform application specific AAA functions.
A separation of AAA functions required in a multi-domain environment is
then proposed using a layered protocol abstraction. The long term goal
is to create a generic framework which allows complex authorizations to
be realized through a network of interconnected AAA servers.",
URL="http://www.rfc-editor.org/rfc/rfc2903.txt"
}

@TECHREPORT{rfc2904,
AUTHOR="J. Vollbrecht and P. Calhoun and S. Farrell and L. Gommans and G. Gross and
B. de Bruijn and Cees {de Laat} and M. Holdrege",
TITLE="{AAA} Authorization Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2904,
PAGES=35,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This memo serves as the base requirements for Authorization of
Internet Resources and Services (AIRS). It presents an architectural
framework for understanding the authorization of Internet resources and
services and derives requirements for authorization protocols.",
URL="http://www.rfc-editor.org/rfc/rfc2904.txt"
}

@TECHREPORT{rfc2905,
AUTHOR="J. Vollbrecht and P. Calhoun and S. Farrell and L. Gommans and G. Gross and
B. de Bruijn and Cees {de Laat} and M. Holdrege",
TITLE="{AAA} Authorization Application Examples",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2905,
PAGES=53,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This memo describes several examples of applications requiring
authorization. Each application is described in terms of a consistent
framework, and specific authorization requirements of each application
are given. This material was not contributed by the working groups
responsible for the applications and should not be considered
prescriptive for how the applications will meet their authorization
needs. Rather the intent is to explore the fundamental needs of a
variety of different applications with the view of compiling a set of
requirements that an authorization protocol will need to meet in order
to be generally useful.",
URL="http://www.rfc-editor.org/rfc/rfc2905.txt"
}

@TECHREPORT{rfc2906,
AUTHOR="S. Farrell and J. Vollbrecht and P. Calhoun and L. Gommans and G. Gross and
B. de Bruijn and Cees {de Laat} and M. Holdrege",
TITLE="{AAA} Authorization Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2906,
PAGES=23,
DAYS=15,
MONTH=aug,
YEAR=2000,
ABSTRACT="This document specifies the requirements that Authentication
Authorization Accounting (AAA) protocols must meet in order to support
authorization services in the Internet. The requirements have been
elicited from a study of a range of applications including mobile-IP,
roamops and others.",
URL="http://www.rfc-editor.org/rfc/rfc2906.txt"
}

@TECHREPORT{rfc2907,
AUTHOR="R. Kermode",
TITLE="{MADCAP} Multicast Scope Nesting State Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2907,
PAGES=13,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document defines a new option to the Multicast Address
Dynamic Client Allocation Protocol (MADCAP) to support nested scoping.
The new option's purpose is to allow clients to learn which scopes nest
inside each other, and hence it may be used for expanding scope searches
or hierarchical multicast transport. This document is a product of the
Multicast-Address Allocation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2907.txt"
}

@TECHREPORT{rfc2908,
AUTHOR="D. Thaler and M. Handley and D. Estrin",
TITLE="The Internet Multicast Address Allocation Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2908,
PAGES=13,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document proposes a multicast address allocation
architecture (MALLOC) for the Internet. The architecture is modular with
three layers, comprising a host-server mechanism, an intra-domain
server-server coordination mechanism, and an inter-domain mechanism.
This document is a product of the Multicast-Address Allocation Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2908.txt"
}

@TECHREPORT{rfc2909,
AUTHOR="P. Radoslavov and D. Estrin and R. Govindan and M. Handley and S. Kumar and
D. Thaler",
TITLE="The Multicast {Address-Set} Claim {(MASC)} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2909,
PAGES=56,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document describes the Multicast Address-Set Claim (MASC)
protocol which can be used for inter-domain multicast address set
allocation. MASC is used by a node (typically a router) to claim and
allocate one or more address prefixes to that node's domain. While a
domain does not necessarily need to allocate an address set for hosts in
that domain to be able to allocate group addresses, allocating an
address set to the domain does ensure that inter-domain group-specific
distribution trees will be locally-rooted, and that traffic will be sent
outside the domain only when and where external receivers exist. This
document is a product of the Multicast-Address Allocation Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2909.txt"
}

@TECHREPORT{rfc2910,
EDITOR="R. Herriot and S. Butler and P. G. Moore",
TITLE="Internet Printing Protocol/1.1: Encoding and Transport",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2910,
PAGES=46,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT={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 Hypertext Transfer Protocol (HTTP) a message
body whose Content-Type is {"}application/ipp{"}. This document defines a
new scheme named 'ipp' for identifying IPP printers and jobs. This
document is a product of the Internet Printing Protocol Working Group of
the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2910.txt"
}

@TECHREPORT{rfc2911,
AUTHOR="T. Hastings and I. W. Ed. and R. Herriot and R. deBry and S. Isaacson and
P. Powell",
TITLE="Internet Printing Protocol/1.1: Model and Semantics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2911,
PAGES=224,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="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.1 semantics allow end-users and operators to
query printer capabilities, submit print jobs, inquire about the status
of print jobs and printers, cancel, hold, release, and restart print
jobs. IPP 1.1 semantics allow operators to pause, resume, and purge
(jobs from) Printer objects. This document also addresses security,
internationalization, and directory issues. This document is a product
of the Internet Printing Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2911.txt"
}

@TECHREPORT{rfc2912,
AUTHOR="G. Klyne",
TITLE="Indicating Media Features for {MIME} Content",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2912,
PAGES=11,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT={In {"}A Syntax for Describing Media Feature Sets{"}, an expression
format is presented for describing media feature capabilities using
simple media feature tags. This memo defines a Multipurpose Internet
Mail Extensions (MIME) 'Content-features:' header that can be used to
annotate a MIME message part using this expression format, and indicates
some ways it might be used. This document is a product of the Content
Negotiation Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2912.txt"
}

@TECHREPORT{rfc2913,
AUTHOR="G. Klyne",
TITLE="{MIME} Content Types in Media Feature Expressions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2913,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT={In {"}A Syntax for Describing Media Feature Sets{"}, an expression
format is presented for describing media feature capabilities using
simple media feature tags. This memo defines a media feature tag whose
value is a Multipurpose Internet Mail Extensions (MIME) content type.
This allows the construction of feature expressions that take account of
the MIME content type of the corresponding data. This document is a
product of the Content Negotiation Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2913.txt"
}

@TECHREPORT{rfc2914,
AUTHOR="S. Floyd",
TITLE="Congestion Control Principles",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2914,
PAGES=17,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="The goal of this document is to explain the need for
congestion control in the Internet, and to discuss what constitutes
correct congestion control. One specific goal is to illustrate the
dangers of neglecting to apply proper congestion control. A second goal
is to discuss the role of the IETF in standardizing new congestion
control protocols.",
URL="http://www.rfc-editor.org/rfc/rfc2914.txt"
}

@TECHREPORT{rfc2915,
AUTHOR="M. Mealling and R. W. Daniel",
TITLE="The Naming Authority Pointer {(NAPTR)} {DNS} Resource Record",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2915,
PAGES=18,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document describes a Domain Name System (DNS) resource
record which specifies a regular expression based rewrite rule that,
when applied to an existing string, will produce a new domain label or
Uniform Resource Identifier (URI). Depending on the value of the flags
field of the resource record, the resulting domain label or URI may be
used in subsequent queries for the Naming Authority Pointer (NAPTR)
resource records (to delegate the name lookup) or as the output of the
entire process for which this system is used (a resolution server for
URI resolution, a service URI for ENUM style e.164 number to URI
mapping, etc). This allows the DNS to be used to lookup services for a
wide variety of resource names (including URIs) which are not in domain
name syntax. Reasons for doing this range from URN Resource Discovery
Systems to moving out-of-date services to new domains. This document
updates the portions of RFC 2168 specifically dealing with the
definition of the NAPTR records and how other, non-URI specific
applications, might use NAPTR. This document is a product of the Uniform
Resource Names Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2915.txt"
}

@TECHREPORT{rfc2916,
AUTHOR="P. Faltstrom",
TITLE="{E.164} number and {DNS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2916,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document discusses the use of the Domain Name System
(DNS) for storage of E.164 numbers. More specifically, how DNS can be
used for identifying available services connected to one E.164 number.
Routing of the actual connection using the service selected using these
methods is not discussed. This document is a product of the Telephone
Number Mapping Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2916.txt"
}

@TECHREPORT{rfc2917,
AUTHOR="K. Muthukrishnan and A. Malis",
TITLE="A Core {MPLS} {IP} {VPN} Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2917,
PAGES=16,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This memo presents an approach for building core Virtual
Private Network (VPN) services in a service provider's MPLS backbone.
This approach uses Multiprotocol Label Switching (MPLS) running in the
backbone to provide premium services in addition to best effort
services. The central vision is for the service provider to provide a
virtual router service to their customers. The keystones of this
architecture are ease of configuration, user security, network security,
dynamic neighbor discovery, scaling and the use of existing routing
protocols as they exist today without any modifications.",
URL="http://www.rfc-editor.org/rfc/rfc2917.txt"
}

@TECHREPORT{rfc2918,
AUTHOR="E. H. Chen",
TITLE="Route Refresh Capability for {BGP-4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2918,
PAGES=4,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document defines a new Border Gateway Protocol (BGP)
capability termed 'Route Refresh Capability', which would allow the
dynamic exchange of route refresh request between BGP speakers and
subsequent re-advertisement of the respective Adj-RIB-Out. One possible
application of this capability is to facilitate non-disruptive routing
policy changes. This document is a product of the Inter-Domain Routing
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2918.txt"
}

@TECHREPORT{rfc2920,
AUTHOR="N. Freed",
TITLE="{SMTP} Service Extension for Command Pipelining",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2920,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This memo defines an extension to the Simple Mail Transfer
Protocol (SMTP) service whereby a server can indicate the extent of its
ability to accept multiple commands in a single Transmission Control
Protocol (TCP) send operation. Using a single TCP send operation for
multiple commands can improve SMTP performance significantly.",
URL="http://www.rfc-editor.org/rfc/rfc2920.txt"
}

@TECHREPORT{rfc2921,
AUTHOR="B. Fink",
TITLE="{6BONE} {pTLA} and {pNLA} Formats {(pTLA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2921,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT={This memo defines how the 6bone uses the 3FFE::/16 IPv6
address prefix, allocated in RFC 2471, {"}IPv6 Testing Address
Allocation{"}, to create pseudo Top-Level Aggregation Identifiers (pTLA's)
and pseudo Next-Level Aggregation Identifiers (pNLA's). This document is
a product of the Next Generation Transition Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2921.txt"
}

@TECHREPORT{rfc2922,
AUTHOR="A. Bierman and K. P. Jones",
TITLE="Physical Topology {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2922,
PAGES=32,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
physical topology identification and discovery. This document is a
product of the Physical Topology MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2922.txt"
}

@TECHREPORT{rfc2923,
AUTHOR="K. Lahey",
TITLE="{TCP} Problems with Path {MTU} Discovery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2923,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This memo catalogs several known Transmission Control Protocol
(TCP) implementation problems dealing with Path Maximum Transmission
Unit Discovery (PMTUD), including the long-standing black hole problem,
stretch acknowlegements (ACKs) due to confusion between Maximum Segment
Size (MSS) and segment size, and MSS advertisement based on PMTU. This
document is a product of the TCP Implementation Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2923.txt"
}

@TECHREPORT{rfc2924,
AUTHOR="Nevil Brownlee and A. Blount",
TITLE="Accounting Attributes and Record Formats",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2924,
PAGES=36,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document summarises Internet Engineering Task Force
(IETF) and International Telecommunication Union (ITU-T) documents
related to Accounting. A classification scheme for the Accounting
Attributes in the summarised documents is presented. Exchange formats
for Accounting data records are discussed, as are advantages and
disadvantages of integrated versus separate record formats and transport
protocols. This document discusses service definition independence
extensibility, and versioning. Compound service definition capabilities
are described. This document is a product of the Authentication,
Authorization and Accounting Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2924.txt"
}

@TECHREPORT{rfc2925,
AUTHOR="K. White",
TITLE="Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup
Operations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2925,
PAGES=77,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This memo defines Management Information Bases (MIBs) for
performing remote ping, traceroute and lookup operations at a remote
host. When managing a network it is useful to be able to initiate and
retrieve the results of ping or traceroute operations when performed at
a remote host. A Lookup capability is defined in order to enable
resolving of either an IP address to an DNS name or an DNS name to an IP
address at a remote host. Currently, there are several
enterprise-specific MIBs for performing remote ping or traceroute
operations. The purpose of this memo is to define a standards-based
solution to enable interoperability. This document is a product of the
Distributed Management Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2925.txt"
}

@TECHREPORT{rfc2926,
AUTHOR="J. Kempf and R. Moats and P. St. Pierre",
TITLE="Conversion of {LDAP} Schemas to and from {SLP} Templates",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2926,
PAGES=27,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document describes a procedure for mapping between
Service Location Protocol (SLP) service advertisements and lightweight
directory access protocol (LDAP) descriptions of services. The document
covers two aspects of the mapping. One aspect is mapping between SLP
service type templates and LDAP directory schema. Because the SLP
service type template grammar is relatively simple, mapping from service
type templates to LDAP types is straightforward. Mapping in the other
direction is straightforward if the attributes are restricted to use
just a few of the syntaxes defined in RFC 2252. If arbitrary ASN.1 types
occur in the schema, then the mapping is more complex and may even be
impossible. The second aspect is representation of service information
in an LDAP directory. The recommended representation simplifies
interoperability with SLP by allowing SLP directory agents to backend
into LDAP directory servers. The resulting system allows service
advertisements to propagate easily between SLP and LDAP. This document
is a product of the Service Location Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2926.txt"
}

@TECHREPORT{rfc2927,
AUTHOR="M. Wahl",
TITLE="{MIME} Directory Profile for {LDAP} Schema",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2927,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document defines a multipurpose internet mail extensions
(MIME) directory profile for holding a lightweight directory access
protocol (LDAP) schema. It is intended for communication with the
Internet schema listing service.",
URL="http://www.rfc-editor.org/rfc/rfc2927.txt"
}

@TECHREPORT{rfc2928,
AUTHOR="R. Hinden and S. E. Deering and R. Fink and T. Hain",
TITLE="Initial {IPv6} {Sub-TLA} {ID} Assignments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2928,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document defines initial assignments of IPv6
Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address
Registries. It is intended as technical input to the Internet Assigned
Numbers Authority (IANA) from the Internet Engineering Task Force (IETF)
Internet Protocol Next Generation (IPNG) and Next Generation Transition
(NGTRANS) working groups, as an input to the process of developing
guidelines for the allocation of IPv6 addresses. This document was
originally developed to provide advice to IANA in the fall of 1998 and
is being published at this time for the historical record. The Internet
Architecture Board (IAB) subsequently requested that the IANA delegate
these assignments to the Address Registries. The IANA did this and the
Address Registries are now using them to assign IPv6 addresses. This
document is a product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2928.txt"
}

@TECHREPORT{rfc2929,
AUTHOR="D. Eastlake 3rd and E. Brunner-Williams and B. Manning",
TITLE="Domain Name System {(DNS)} {IANA} Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2929,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System (DNS)
classes, Resource Record (RR) types, operation codes, error codes, etc.
This document is a product of the DNS Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2929.txt"
}

@TECHREPORT{rfc2930,
AUTHOR="D. Eastlake 3rd",
TITLE="Secret Key Establishment for {DNS} {(TKEY} {RR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2930,
PAGES=16,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="[RFC 2845] provides a means of authenticating Domain Name
System (DNS) queries and responses using shared secret keys via the
Transaction Signature (TSIG) resource record (RR). However, it provides
no mechanism for setting up such keys other than manual exchange. This
document describes a Transaction Key (TKEY) RR that can be used in a
number of different modes to establish shared secret keys between a DNS
resolver and server. This document is a product of the DNS Extensions
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2930.txt"
}

@TECHREPORT{rfc2931,
AUTHOR="D. Eastlake 3rd",
TITLE="{DNS} Request and Transaction Signatures ( {SIG(0)s)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2931,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="Extensions to the Domain Name System (DNS) are described in
[RFC 2535] that can provide data origin and transaction integrity and
authentication to security aware resolvers and applications through the
use of cryptographic digital signatures. Implementation experience has
indicated the need for minor but non-interoperable changes in Request
and Transaction signature resource records ( SIG(0)s ). These changes
are documented herein. This document is a product of the DNS Extensions
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2931.txt"
}

@TECHREPORT{rfc2932,
AUTHOR="K. McCloghrie and D. Farinacci and D. Thaler",
TITLE="{IPv4} Multicast Routing {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2932,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
IP Multicast Routing for IPv4, independent of the specific multicast
routing protocol in use. This document is a product of the Inter-Domain
Multicast Routing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2932.txt"
}

@TECHREPORT{rfc2933,
AUTHOR="K. McCloghrie and D. Farinacci and D. Thaler",
TITLE="Internet Group Management Protocol {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2933,
PAGES=19,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing the
Internet Group Management Protocol (IGMP). This document is a product of
the Inter-Domain Multicast Routing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2933.txt"
}

@TECHREPORT{rfc2934,
AUTHOR="K. McCloghrie and D. Farinacci and D. Thaler and B. Fenner",
TITLE="Protocol Independent Multicast {MIB} for {IPv4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2934,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
the Protocol Independent Multicast (PIM) protocol for IPv4. This
document is a product of the Inter-Domain Multicast Routing Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2934.txt"
}

@TECHREPORT{rfc2935,
AUTHOR="D. Eastlake 3rd and C. U. Smith",
TITLE="Internet Open Trading Protocol {(IOTP)} {HTTP} Supplement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2935,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="Internet Open Trading Protocol (IOTP) messages will be carried
as Extensible Markup Language (XML) documents. As such, the goal of
mapping to the transport layer is to ensure that the underlying XML
documents are carried successfully between the various parties. This
document describes that mapping for the Hyper Text Transport Protocol
(HTTP), Versions 1.0 and 1.1. This document is a product of the Internet
Open Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2935.txt"
}

@TECHREPORT{rfc2936,
AUTHOR="D. Eastlake 3rd and C. U. Smith and D. Soroka",
TITLE="{HTTP} {MIME} Type Handler Detection",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2936,
PAGES=13,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="Entities composing web pages to provide services over the
Hypertext Transfer Protocol (HTTP) frequently have the problem of not
knowing what Multipurpose Internet Mail Extensions (MIME) types have
handlers installed at a user's browser. For example, whether an Internet
Open Trading Protocol (IOTP) or VRML or SET or some streaming media
handler is available. In some cases they would want to display different
web pages or content depending on a MIME handler's availability. This
document summarizes reasonable techniques to solve this problem for most
of the browsers actually deployed on the Internet as of early 2000. It
is intended to be of practical use to implementors during the period
before the wide deployment of superior standards based techniques which
may be developed. This document is a product of the Internet Open
Trading Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2936.txt"
}

@TECHREPORT{rfc2937,
AUTHOR="C. U. Smith",
TITLE="The Name Service Search Option for {DHCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2937,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document defines a new Dynamic Host Configuration
Protocol (DHCP) option which is passed from the DHCP Server to the DHCP
Client to specify the order in which name services should be consulted
when resolving hostnames and other information. This document is a
product of the Dynamic Host Configuration Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2937.txt"
}

@TECHREPORT{rfc2938,
AUTHOR="G. Klyne and L. Masinter",
TITLE="Identifying Composite Media Features",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2938,
PAGES=18,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="In RFC 2533, an expression format is presented for describing
media feature capabilities as a combination of simple media feature
tags. This document describes an abbreviated format for a composite
media feature set, based upon a hash of the feature expression
describing that composite. This document is a product of the Content
Negotiation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2938.txt"
}

@TECHREPORT{rfc2939,
AUTHOR="R. E. Droms",
TITLE="Procedures and {IANA} Guidelines for Definition of New {DHCP} Options and
Message Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2939,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT={The Dynamic Host Configuration Protocol (DHCP) provides a
framework for passing configuration information to hosts on a
Transmission Control Protocol/Internet Protocol (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{"}. DHCP
protocol messages are identified by the 'DHCP Message Type' option
(option code 51). Each message type is defined by the data value carried
in the 'DHCP Message Type' option. New DHCP options and message types
may be defined after the publication of the DHCP specification to
accommodate requirements for conveyance of new configuration parameters
or to accommodate new protocol semantics. This document describes the
procedure for defining new DHCP options and message types. This document
is a product of the Dynamic Host Configuration Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2939.txt"
}

@TECHREPORT{rfc2940,
AUTHOR="A. J. Smith and D. Partain and J. Seligson",
TITLE="Definitions of Managed Objects for Common Open Policy Service {(COPS)}
Protocol Clients",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2940,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular it defines objects for managing a client of the
Common Open Policy Service (COPS) protocol. This memo includes a MIB
module in a manner that is compliant to the SMIv2 [V2SMI].",
URL="http://www.rfc-editor.org/rfc/rfc2940.txt"
}

@TECHREPORT{rfc2941,
EDITOR="T. Ts'o and J. Altman",
TITLE="Telnet Authentication Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2941,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document describes the authentication option to the
telnet protocol as a generic method for negotiating an authentication
type and mode including whether encryption should be used and if
credentials should be forwarded. While this document summarizes
currently utilized commands and types it does not define a specific
authentication type. Separate documents are to be published defining
each authentication type. This document updates a previous specification
of the telnet authentication option, RFC 1416, so that it can be used to
securely enable the telnet encryption option.",
URL="http://www.rfc-editor.org/rfc/rfc2941.txt"
}

@TECHREPORT{rfc2942,
AUTHOR="T. Ts'o",
TITLE="Telnet Authentication: Kerberos Version 5",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2942,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document describes how Kerberos Version 5 is used with
the telnet protocol. It describes an telnet authentication suboption to
be used with the telnet authentication option. This mechanism can also
used to provide keying material to provide data confidentiality services
in conjunction with the telnet encryption option.",
URL="http://www.rfc-editor.org/rfc/rfc2942.txt"
}

@TECHREPORT{rfc2943,
AUTHOR="R. Housley and T. Horting and P. Yee",
TITLE="{TELNET} Authentication Using {DSA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2943,
PAGES=12,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document defines a telnet authentication mechanism using
the Digital Signature Algorithm (DSA). It relies on the Telnet
Authentication Option",
URL="http://www.rfc-editor.org/rfc/rfc2943.txt"
}

@TECHREPORT{rfc2944,
AUTHOR="T. Wu",
TITLE="Telnet Authentication: {SRP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2944,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document specifies an authentication scheme for the
Telnet protocol under the framework described in RFC 2941, using the
Secure Remote Password Protocol (SRP) authentication mechanism. The
specific mechanism, SRP-SHA1, is described in RFC 2945.",
URL="http://www.rfc-editor.org/rfc/rfc2944.txt"
}

@TECHREPORT{rfc2945,
AUTHOR="T. Wu",
TITLE="The {SRP} Authentication and Key Exchange System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2945,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document describes a cryptographically strong network
authentication mechanism known as the Secure Remote Password (SRP)
protocol. This mechanism is suitable for negotiating secure connections
using a user-supplied password, while eliminating the security problems
traditionally associated with reusable passwords. This system also
performs a secure key exchange in the process of authentication,
allowing security layers (privacy and/or integrity protection) to be
enabled during the session. Trusted key servers and certificate
infrastructures are not required, and clients are not required to store
or manage any long-term keys. SRP offers both security and deployment
advantages over existing challenge-response techniques, making it an
ideal drop-in replacement where secure password authentication is
needed.",
URL="http://www.rfc-editor.org/rfc/rfc2945.txt"
}

@TECHREPORT{rfc2946,
AUTHOR="T. Ts'o",
TITLE="Telnet Data Encryption Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2946,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document describes a the telnet encryption option as a
generic method of providing data confidentiality services for the telnet
data stream. While this document summarizes currently utilized
encryption types and codes, it does not define a specific encryption
algorithm. Separate documents are to be published defining
implementations of this option for each encryption algorithm.",
URL="http://www.rfc-editor.org/rfc/rfc2946.txt"
}

@TECHREPORT{rfc2947,
AUTHOR="J. Altman",
TITLE="Telnet Encryption: {DES3} 64 bit Cipher Feedback",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2947,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document specifies how to use the Triple-DES (data
encryption standard) encryption algorithm in cipher feedback mode with
the telnet encryption option.",
URL="http://www.rfc-editor.org/rfc/rfc2947.txt"
}

@TECHREPORT{rfc2948,
AUTHOR="J. Altman",
TITLE="Telnet Encryption: {DES3} 64 bit Output Feedback",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2948,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document specifies how to use the Triple-DES (data
encryption standard) encryption algorithm in output feedback mode with
the telnet encryption option.",
URL="http://www.rfc-editor.org/rfc/rfc2948.txt"
}

@TECHREPORT{rfc2949,
AUTHOR="J. Altman",
TITLE="Telnet Encryption: {CAST-128} 64 bit Output Feedback",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2949,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document specifies how to use the CAST-128 encryption
algorithm in output feedback mode with the telnet encryption option. Two
key sizes are defined: 40 bit and 128 bit.",
URL="http://www.rfc-editor.org/rfc/rfc2949.txt"
}

@TECHREPORT{rfc2950,
AUTHOR="J. Altman",
TITLE="Telnet Encryption: {CAST-128} 64 bit Cipher Feedback",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2950,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document specifies how to use the CAST-128 encryption
algorithm in cipher feedback mode with the telnet encryption option. Two
key sizes are defined: 40 bit and 128 bit.",
URL="http://www.rfc-editor.org/rfc/rfc2950.txt"
}

@TECHREPORT{rfc2951,
AUTHOR="R. Housley and T. Horting and P. Yee",
TITLE="{TELNET} Authentication Using {KEA} and {SKIPJACK}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2951,
PAGES=11,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document defines a method to authenticate TELNET using
the Key Exchange Algorithm (KEA), and encryption of the TELNET stream
using SKIPJACK. Two encryption modes are specified; one provides data
integrity and the other does not. The method relies on the TELNET
Authentication Option.",
URL="http://www.rfc-editor.org/rfc/rfc2951.txt"
}

@TECHREPORT{rfc2952,
AUTHOR="T. Ts'o",
TITLE="Telnet Encryption: {DES} 64 bit Cipher Feedback",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2952,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document specifies how to use the DES encryption
algorithm in cipher feedback mode with the telnet encryption option.",
URL="http://www.rfc-editor.org/rfc/rfc2952.txt"
}

@TECHREPORT{rfc2953,
AUTHOR="T. Ts'o",
TITLE="Telnet Encryption: {DES} 64 bit Output Feedback",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2953,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2000,
ABSTRACT="This document specifies how to use the data encryption
standard (DES) encryption algorithm in output feedback mode with the
telnet encryption option.",
URL="http://www.rfc-editor.org/rfc/rfc2953.txt"
}

@TECHREPORT{rfc2954,
AUTHOR="K. Rehbehn and D. Fowler",
TITLE="Definitions of Managed Objects for Frame Relay Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2954,
PAGES=76,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines an extension to the Management Information
Base (MIB) for use with network management protocols in Transmission
Control Protocol/Internet Protocol-based (TCP/IP) internets. In
particular, it defines objects for managing the frame relay service.
This document is a product of the Frame Relay Service MIB Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2954.txt"
}

@TECHREPORT{rfc2955,
AUTHOR="K. Rehbehn and O. Nicklass and G. Mouradian",
TITLE="Definitions of Managed Objects for Monitoring and Controlling the Frame
{Relay/ATM} {PVC} Service Interworking Function",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2955,
PAGES=39,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines a Management Information Base (MIB) to
configure, monitor, and control a service interworking function (IWF)
for Permanent Virtual Connections (PVC) between Frame Relay and
Asynchronous Transfer Mode (ATM) technologies. This document is a
product of the Frame Relay Service MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2955.txt"
}

@TECHREPORT{rfc2956,
AUTHOR="M. Kaat",
TITLE="Overview of 1999 {IAB} Network Layer Workshop",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2956,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document is an overview of a workshop held by the
Internet Architecture Board (IAB) on the Internet Network Layer
architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July
1999. The goal of the workshop was to understand the state of the
network layer and its impact on continued growth and usage of the
Internet. Different technical scenarios for the (foreseeable) future and
the impact of external influences were studied. This report lists the
conclusions and recommendations to the Internet Engineering Task Force
(IETF) community. This document is a product of the Internet
Architecture Board.",
URL="http://www.rfc-editor.org/rfc/rfc2956.txt"
}

@TECHREPORT{rfc2957,
AUTHOR="L. Daigle and P. Faltstrom",
TITLE="The application/whoispp-query {Content-Type}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2957,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document defines the expression of Whois++ protocol
queries within MIME (Multipurpose Internet Mail Extensions) media types.
The intention of this document, in conjunction with RFC 2958 is to
enable MIME-enabled mail software, and other systems using Internet
media types, to carry out Whois++ transactions.",
URL="http://www.rfc-editor.org/rfc/rfc2957.txt"
}

@TECHREPORT{rfc2958,
AUTHOR="L. Daigle and P. Faltstrom",
TITLE="The application/whoispp-response Content-type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2958,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document defines the expression of Whois++ protocol
responses within MIME (Multipurpose Internet Mail Extensions) media
types. The intention of this document, in conjunction with RFC 2957 is
to enable MIME-enabled mail software, and other systems using Internet
media types, to carry out Whois++ transactions.",
URL="http://www.rfc-editor.org/rfc/rfc2958.txt"
}

@TECHREPORT{rfc2959,
AUTHOR="M. Baugher and B. Strahm and I. Suconick",
TITLE="{Real-Time} Transport Protocol Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2959,
PAGES=31,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing Real-Time
Transport Protocol (RTP) systems. This document is a product of the
Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2959.txt"
}

@TECHREPORT{rfc2960,
AUTHOR="R. J. Stewart and Q. Xie and K. Morneault and C. Sharp and H. Schwarzbauer
and T. Taylor and I. Rytina and M. Kalla",
TITLE="Stream Control Transmission Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2960,
PAGES=134,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document describes the Stream Control Transmission
Protocol (SCTP). SCTP is designed to transport PSTN signaling messages
over IP networks, but is capable of broader applications. SCTP is a
reliable transport protocol operating on top of a connectionless packet
network such as IP. It offers the following services to its users:
acknowledged error-free non-duplicated transfer of user data, data
fragmentation to conform to discovered path MTU size, sequenced delivery
of user messages within multiple streams, with an option for
order-of-arrival delivery of individual user messages, optional bundling
of multiple user messages into a single SCTP packet, and network-level
fault tolerance through supporting of multi-homing at either or both
ends of an association. The design of SCTP includes appropriate
congestion avoidance behavior and resistance to flooding and masquerade
attacks.",
URL="http://www.rfc-editor.org/rfc/rfc2960.txt"
}

@TECHREPORT{rfc2962,
AUTHOR="D. Raz and J. Schoenwaelder and B. Sugla",
TITLE="An {SNMP} Application Level Gateway for Payload Address Translation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2962,
PAGES=20,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document describes the ALG (Application Level Gateway)
for the SNMP (Simple Network Management Protocol) by which IP (Internet
Protocol) addresses in the payload of SNMP packets are statically mapped
from one group to another. The SNMP ALG is a specific case of an
Application Level Gateway as described in RFC 2663. An SNMP ALG allows
network management stations to manage multiple networks that use
conflicting IP addresses. This can be important in environments where
there is a need to use SNMP with NAT (Network Address Translator) in
order to manage several potentially overlapping addressing realms. This
document includes a detailed description of the requirements and
limitations for an implementation of an SNMP Application Level Gateway.
It also discusses other approaches to exchange SNMP packets across
conflicting addressing realms. This document is a product of the Network
Address Translators Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2962.txt"
}

@TECHREPORT{rfc2963,
AUTHOR="O. Bonaventure and Stefaan De Cnodder",
TITLE="A Rate Adaptive Shaper for Differentiated Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2963,
PAGES=19,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo describes several Rate Adaptive Shapers (RAS) that
can be used in combination with the single rate Three Color Markers
(srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697
and RFC2698, respectively. These RAS improve the performance of TCP when
a TCM is used at the ingress of a diffserv network by reducing the
burstiness of the traffic. With TCP traffic, this reduction of the
burstiness is accompanied by a reduction of the number of marked packets
and by an improved TCP goodput. The proposed RAS can be used at the
ingress of Diffserv networks providing the Assured Forwarding Per Hop
Behavior (AF PHB). They are especially useful when a TCM is used to mark
traffic composed of a small number of TCP connections.",
URL="http://www.rfc-editor.org/rfc/rfc2963.txt"
}

@TECHREPORT{rfc2964,
AUTHOR="K. Moore and N. Freed",
TITLE="Use of {HTTP} State Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2964,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT={The mechanisms described in {"}HTTP State Management Mechanism{"}
(RFC-2965), and its predecessor (RFC-2109), can be used for many
different purposes. However, some current and potential uses of the
protocol are controversial because they have significant user privacy
and security implications. This memo identifies specific uses of
Hypertext Transfer Protocol (HTTP) State Management protocol which are
either (a) not recommended by the IETF, or (b) believed to be harmful,
and discouraged. This memo also details additional privacy
considerations which are not covered by the HTTP State Management
protocol specification.},
URL="http://www.rfc-editor.org/rfc/rfc2964.txt"
}

@TECHREPORT{rfc2965,
AUTHOR="D. Kristol and L. Montulli",
TITLE="{HTTP} State Management Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2965,
PAGES=26,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document specifies a way to create a stateful session
with Hypertext Transfer Protocol (HTTP) requests and responses. It
describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
carry state information between participating origin servers and user
agents. The method described here differs from Netscape's Cookie
proposal, but it can interoperate with HTTP/1.0 user agents that use
Netscape's method. This document reflects implementation experience with
RFC 2109 and obsoletes it.",
URL="http://www.rfc-editor.org/rfc/rfc2965.txt"
}

@TECHREPORT{rfc2966,
AUTHOR="T. Li and T. Przygienda and H. Smit",
TITLE="Domain-wide Prefix Distribution with {Two-Level} {IS-IS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2966,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document describes extensions to the Intermediate System
to Intermediate System (IS-IS) protocol to support optimal routing
within a two-level domain. The IS-IS protocol is specified in ISO 10589,
with extensions for supporting IPv4 (Internet Protocol) specified in RFC
1195. This document extends the semantics presented in RFC 1195 so that
a routing domain running with both level 1 and level 2 Intermediate
Systems (IS) [routers] can distribute IP prefixes between level 1 and
level 2 and vice versa. This distribution requires certain restrictions
to insure that persistent forwarding loops do not form. The goal of this
domain-wide prefix distribution is to increase the granularity of the
routing information within the domain. This document is a product of the
IS-IS for IP Internets Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2966.txt"
}

@TECHREPORT{rfc2967,
AUTHOR="L. Daigle and R. Hedberg",
TITLE="{TISDAG} - Technical Infrastructure for Swedish Directory Access Gateways",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2967,
PAGES=105,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="The strength of the TISDAG (Technical Infrastructure for
Swedish Directory Access Gateways) project's DAG proposal is that it
defines the necessary technical infrastructure to provide a
single-access-point service for information on Swedish Internet users.
The resulting service will provide uniform access for all information --
the same level of access to information (7x24 service), and the same
information made available, irrespective of the service provider
responsible for maintaining that information, their directory service
protocols, or the end-user's client access protocol.",
URL="http://www.rfc-editor.org/rfc/rfc2967.txt"
}

@TECHREPORT{rfc2968,
AUTHOR="L. Daigle and T. Eklof",
TITLE="Mesh of Multiple {DAG} servers - Results from {TISDAG}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2968,
PAGES=9,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="The Common Indexing Protocol ([CIP1]) is designed to
facilitate the creation not only of query referral indexes, but also of
meshes of (loosely) affiliated referral indexes. The purpose of such a
mesh of servers is to implement some kind of distributed sharing of
indexing and/or searching tasks across different servers. So far, the
TISDAG (Technical Infrastructure for Swedish Directory Access Gateways)
project ([TISDAG], [DAGEXP]) has focused on creating a single referral
index; the obvious next step is to integrate that into a larger set of
interoperating services.",
URL="http://www.rfc-editor.org/rfc/rfc2968.txt"
}

@TECHREPORT{rfc2969,
AUTHOR="T. Eklof and L. Daigle",
TITLE="Wide Area Directory Deployment - Experiences from {TISDAG}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2969,
PAGES=19,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="The TISDAG (Technical Infrastructure for Swedish Directory
Access Gateway) project provided valuable insight into the current
reality of deploying a wide-scale directory service. This document
catalogues some of the experiences gained in developing the necessary
infrastructure for a national (i.e., multi-organizational) directory
service and pilot deployment of the service in an environment with
off-the-shelf directory service products. A perspective on the project's
relationship to other directory deployment projects is provided, along
with some proposals for future extensions of the work (larger scale
deployment, other application areas). These are our own observations,
based on work done and general project discussions. No doubt, other
project participants have their own list of project experiences; we
don't claim this document is exhaustive!",
URL="http://www.rfc-editor.org/rfc/rfc2969.txt"
}

@TECHREPORT{rfc2970,
AUTHOR="L. Daigle and T. Eklof",
TITLE="Architecture for Integrated Directory Services - Result from {TISDAG}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2970,
PAGES=18,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="A single, unified, global whitepages directory service remains
elusive. Nonetheless, there is increasing call for participation of
widely-dispersed directory servers (i.e., across multiple organizations)
in large-scale directory services. These services range from national
whitepages services, to multi-national indexes of WWW resources, and
beyond. Drawing from experiences with the TISDAG (Technical
Infrastructure for Swedish Directory Access Gateways) ([TISDAG])
project, this document outlines an approach to providing the necessary
infrastructure for integrating such widely-scattered servers into a
single service, rather than attempting to mandate a single protocol and
schema set for all participating servers to use.",
URL="http://www.rfc-editor.org/rfc/rfc2970.txt"
}

@TECHREPORT{rfc2971,
AUTHOR="T. Showalter",
TITLE="{IMAP4} {ID} extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2971,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="The ID extension to the Internet Message Access Protocol -
Version 4rev1 (IMAP4rev1) protocol allows the server and client to
exchange identification information on their implementation in order to
make bug reports and usage statistics more complete.",
URL="http://www.rfc-editor.org/rfc/rfc2971.txt"
}

@TECHREPORT{rfc2972,
AUTHOR="N. Popp and M. Mealling and L. Masinter and K. Sollins",
TITLE="Context and Goals for Common Name Resolution",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2972,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT={This document establishes the context and goals for a Common
Name Resolution Protocol. It defines the terminology used concerning a
{"}Common Name{"} and how one might be {"}resolved{"}, and establishes the
distinction between {"}resolution{"} and more elaborate search mechanisms.
It establishes some expected contexts for use of Common Name Resolution,
and the criteria for evaluating a successful protocol. It also analyzes
the various motivations that would cause services to provide Common Name
resolution for both public, private and commercial use.},
URL="http://www.rfc-editor.org/rfc/rfc2972.txt"
}

@TECHREPORT{rfc2973,
AUTHOR="R. Balay and D. Katz and J. B. Parker",
TITLE="{IS-IS} Mesh Groups",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2973,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document describes a mechanism to reduce redundant packet
transmissions for the Intermediate System to Intermediate System (IS-IS)
Routing protocol, as described in ISO 10589. The described mechanism can
be used to reduce the flooding of Link State PDUs (Protocol Data Units)
(LSPs) in IS-IS topologies. The net effect is to engineer a flooding
topology for LSPs which is a subset of the physical topology. This
document serves to document the existing behavior in deployed
implementations. The document describes behaviors that are backwards
compatible with implementations that do not support this feature. This
document is a product of the IS-IS for IP Internets Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2973.txt"
}

@TECHREPORT{rfc2974,
AUTHOR="M. Handley and C. E. Perkins and E. Whelan",
TITLE="Session Announcement Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2974,
PAGES=18,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document describes version 2 of the multicast session
directory announcement protocol, Session Announcement Protocol (SAP),
and the related issues affecting security and scalability that should be
taken into account by implementors. This document is a product of the
Multiparty Multimedia Session Control Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2974.txt"
}

@TECHREPORT{rfc2975,
AUTHOR="B. Aboba and J. Arkko and D. Harrington",
TITLE="Introduction to Accounting Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2975,
PAGES=54,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="The field of Accounting Management is concerned with the
collection of resource consumption data for the purposes of capacity and
trend analysis, cost allocation, auditing, and billing. This document
describes each of these problems, and discusses the issues involved in
design of modern accounting systems. Since accounting applications do
not have uniform security and reliability requirements, it is not
possible to devise a single accounting protocol and set of security
services that will meet all needs. Thus the goal of accounting
management is to provide a set of tools that can be used to meet the
requirements of each application. This document describes the currently
available tools as well as the state of the art in accounting protocol
design. A companion document, RFC 2924, reviews the state of the art in
accounting attributes and record formats. This document is a product of
the Authentication, Authorization and Accounting Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2975.txt"
}

@TECHREPORT{rfc2976,
AUTHOR="S. Donovan",
TITLE="The {SIP} {INFO} Method",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2976,
PAGES=9,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document proposes an extension to the Session Initiation
Protocol (SIP). This extension adds the INFO method to the SIP protocol.
The intent of the INFO method is to allow for the carrying of session
related control information that is generated during a session. One
example of such session control information is ISUP and ISDN signaling
messages used to control telephony call services. This and other example
uses of the INFO method may be standardized in the future. This document
is a product of the Session Initiation Protocol Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2976.txt"
}

@TECHREPORT{rfc2977,
AUTHOR="S. Glass and T. Hiller and S. Jacobs and C. E. Perkins",
TITLE="Mobile {IP} Authentication, Authorization, and Accounting Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2977,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="The Mobile IP and Authentication, Authorization, Accounting
(AAA) working groups are currently looking at defining the requirements
for Authentication, Authorization, and Accounting. This document
contains the requirements which would have to be supported by a AAA
service to aid in providing Mobile IP services. This document is a
product of the IP Routing for Wireless/Mobile Hosts Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2977.txt"
}

@TECHREPORT{rfc2978,
AUTHOR="N. Freed and J. B. Postel",
TITLE="{IANA} Charset Registration Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2978,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="Multipurpose Internet Mail Extensions (MIME) (RFC-2045,
RFC-2046, RFC-2047, RFC-2184) and various other Internet protocols are
capable of using many different charsets. This in turn means that the
ability to label different charsets is essential. Note: The charset
registration procedure exists solely to associate a specific name or
names with a given charset and to give an indication of whether or not a
given charset can be used in MIME text objects. In particular, the
general applicability and appropriateness of a given registered charset
to a particular application is a protocol issue, not a registration
issue, and is not dealt with by this registration procedure.",
URL="http://www.rfc-editor.org/rfc/rfc2978.txt"
}

@TECHREPORT{rfc2979,
AUTHOR="N. Freed",
TITLE="Behavior of and Requirements for Internet Firewalls",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2979,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines behavioral characteristics of and
interoperability requirements for Internet firewalls. While most of
these things may seem obvious, current firewall behavior is often either
unspecified or underspecified and this lack of specificity often causes
problems in practice. This requirement is intended to be a necessary
first step in making the behavior of firewalls more consistent across
implementations and in line with accepted IP protocol practices. This
document is a product of the Internet Architecture Board.",
URL="http://www.rfc-editor.org/rfc/rfc2979.txt"
}

@TECHREPORT{rfc2980,
AUTHOR="S. E. Barber",
TITLE="Common {NNTP} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2980,
PAGES=27,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="In this document, a number of popular extensions to the
Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are
documented and discussed. While this document is not intended to serve
as a standard of any kind, it will hopefully serve as a reference
document for future implementers of the NNTP protocol. In the role, this
document would hopefully create the possibility for some level of
interoperability among implementations that make use of extensions. This
document is a product of the NNTP Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2980.txt"
}

@TECHREPORT{rfc2981,
AUTHOR="Ramanathan Kavasseri",
TITLE="Event {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2981,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects that can be used
to manage and monitor MIB objects and take action through events. The
Event MIB provides the ability to monitor MIB objects on the local
system or on a remote system and take simple action when a trigger
condition is met. This document is a product of the Distributed
Management Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2981.txt"
}

@TECHREPORT{rfc2982,
AUTHOR="Ramanathan Kavasseri",
TITLE="Distributed Management Expression {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2982,
MONTH=oct,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
expressions of MIB objects. The results of these expressions become MIB
objects usable like any other MIB object, such as for the test condition
for declaring an event. This document is a product of the Distributed
Management Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2982.txt"
}

@TECHREPORT{rfc2983,
AUTHOR="D. L. Black",
TITLE="Differentiated Services and Tunnels",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2983,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document considers the interaction of Differentiated
Services (diffserv) (RFC 2474, RFC 2475) with IP tunnels of various
forms. The discussion of tunnels in the diffserv architecture (RFC 2475)
provides insufficient guidance to tunnel designers and implementers.
This document describes two conceptual models for the interaction of
diffserv with Internet Protocol (IP) tunnels and employs them to explore
the resulting configurations and combinations of functionality. An
important consideration is how and where it is appropriate to perform
diffserv traffic conditioning in the presence of tunnel encapsulation
and decapsulation. A few simple mechanisms are also proposed that limit
the complexity that tunnels would otherwise add to the diffserv traffic
conditioning model. Security considerations for IPSec tunnels limit the
possible functionality in some circumstances. This document is a product
of the Differentiated Services Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2983.txt"
}

@TECHREPORT{rfc2984,
AUTHOR="C. J. Adams",
TITLE="Use of the {CAST-128} Encryption Algorithm in {CMS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2984,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=2000,
ABSTRACT="This document specifies how to incorporate CAST-128 (RFC2144)
into the S/MIME Cryptographic Message Syntax (CMS) as an additional
algorithm for symmetric encryption. The relevant OIDs and processing
steps are provided so that CAST-128 may be included in the CMS
specification (RFC2630) for symmetric content and key encryption. This
document is a product of the S/MIME Mail Security Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2984.txt"
}

@TECHREPORT{rfc2985,
AUTHOR="M. Nystrom and B. Kaliski",
TITLE="{PKCS} {#9:} Selected Object Classes and Attribute Types Version {2.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2985,
PAGES=42,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This memo represents a republication of PKCS #9 v2.0 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process. The body of this
document, except for the security considerations section, is taken
directly from that specification. This memo provides a selection of
object classes and attribute types for use in conjunction with
public-key cryptography and Lightweight Directory Access Protocol (LDAP)
accessible directories. It also includes ASN.1 syntax for all
constructs.",
URL="http://www.rfc-editor.org/rfc/rfc2985.txt"
}

@TECHREPORT{rfc2986,
AUTHOR="M. Nystrom and B. Kaliski",
TITLE="{PKCS} {#10:} Certification Request Syntax Specification Version {1.7}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2986,
PAGES=14,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This memo represents a republication of PKCS #10 v1.7 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process. The body of this
document, except for the security considerations section, is taken
directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo
describes a syntax for certification requests.",
URL="http://www.rfc-editor.org/rfc/rfc2986.txt"
}

@TECHREPORT{rfc2987,
AUTHOR="P. Hoffman",
TITLE="Registration of Charset and Languages Media Features Tags",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2987,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT={This document contains the registration for two media feature
tags: {"}charset{"} and {"}language{"}. These media features allow
specification
of character sets and human languages that can be understood by devices
and the devices' users. The templates in this document are derived from
RFC 2506.},
URL="http://www.rfc-editor.org/rfc/rfc2987.txt"
}

@TECHREPORT{rfc2988,
AUTHOR="V. Paxson and M. Allman",
TITLE="Computing {TCP's} Retransmission Timer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2988,
PAGES=8,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document defines the standard algorithm that Transmission
Control Protocol (TCP) senders are required to use to compute and manage
their retransmission timer. It expands on the discussion in section
4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the
algorithm from a SHOULD to a MUST. This document is a product of the
Transport Area Working Group Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2988.txt"
}

@TECHREPORT{rfc2989,
AUTHOR="B. Aboba and P. Calhoun and S. Glass and T. Hiller and P. McCann and H.
Shiino and G. Zorn and G. Dommety",
TITLE="Criteria for Evaluating {AAA} Protocols for Network Access",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2989,
PAGES=28,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document represents a summary of Authentication,
Authorization, Accounting (AAA) protocol requirements for network
access. In creating this document, inputs were taken from documents
produced by the Network Access Server Requirements Next Generation
(NASREQ), Roaming Operations (ROAMOPS), and MOBILEIP working groups, as
well as from TIA 45.6. This document summarizes the requirements
collected from those sources, separating requirements for
authentication, authorization and accounting. Details on the
requirements are available in the original documents. This document is a
product of the Authentication, Authorization and Accounting Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2989.txt"
}

@TECHREPORT{rfc2990,
AUTHOR="G. Huston",
TITLE="Next Steps for the {IP} {QoS} Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2990,
PAGES=24,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="While there has been significant progress in the definition of
Quality of Service (QoS) architectures for internet networks, there are
a number of aspects of QoS that appear to need further elaboration as
they relate to translating a set of tools into a coherent platform for
end-to-end service delivery. This document highlights the outstanding
architectural issues relating to the deployment and use of QoS
mechanisms within internet networks, noting those areas where further
standards work may assist with the deployment of QoS internets. This
document is a product of the Internet Architecture Board.",
URL="http://www.rfc-editor.org/rfc/rfc2990.txt"
}

@TECHREPORT{rfc2991,
AUTHOR="D. Thaler and C. Hopps",
TITLE="Multipath Issues in Unicast and Multicast {Next-Hop} Selection",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2991,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT={Various routing protocols, including Open Shortest Path First
(OSPF) and Intermediate System to Intermediate System (ISIS), explicitly
allow {"}Equal-Cost Multipath{"} (ECMP) routing. Some router
implementations
also allow equal-cost multipath usage with RIP and other routing
protocols. The effect of multipath routing on a forwarder is that the
forwarder potentially has several next-hops for any given destination
and must use some method to choose which next- hop should be used for a
given data packet.},
URL="http://www.rfc-editor.org/rfc/rfc2991.txt"
}

@TECHREPORT{rfc2992,
AUTHOR="C. Hopps",
TITLE="Analysis of an {Equal-Cost} {Multi-Path} Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2992,
PAGES=8,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="Equal-cost multi-path (ECMP) is a routing technique for
routing packets along multiple paths of equal cost. The forwarding
engine identifies paths by next-hop. When forwarding a packet the router
must decide which next-hop (path) to use. This document gives an
analysis of one method for making that decision. The analysis includes
the performance of the algorithm and the disruption caused by changes to
the set of next-hops.",
URL="http://www.rfc-editor.org/rfc/rfc2992.txt"
}

@TECHREPORT{rfc2993,
AUTHOR="T. Hain",
TITLE="Architectural Implications of {NAT}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2993,
PAGES=29,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="In light of the growing interest in, and deployment of network
address translation (NAT) RFC-1631, this paper will discuss some of the
architectural implications and guidelines for implementations. It is
assumed the reader is familiar with the address translation concepts
presented in RFC-1631.",
URL="http://www.rfc-editor.org/rfc/rfc2993.txt"
}

@TECHREPORT{rfc2994,
AUTHOR="H. Ohta and M. Matsui",
TITLE="A Description of the {MISTY1} Encryption Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2994,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document describes a secret-key cryptosystem MISTY1,
which is block cipher with a 128-bit key, a 64-bit block and a variable
number of rounds. It documents the algorithm description including key
scheduling part and data randomizing part.",
URL="http://www.rfc-editor.org/rfc/rfc2994.txt"
}

@TECHREPORT{rfc2995,
AUTHOR="H. Lu and I. W. Ed. and I. Faynberg and J. Voelker and M. D. Weissman and
W. Zhang and S. Rhim and J. Hwang",
TITLE="{Pre-Spirits} Implementations of {PSTN-initiated} Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2995,
PAGES=44,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document contains information relevant to the work
underway in The Services in the PSTN/IN Requesting InTernet Services
(SPIRITS) Working Group. It describes four existing implementations of
SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and
Telia in cooperation with Nortel Networks. SPIRITS-like services are
those originating in the Public Switched Telephone Network (PSTN) and
necessitating the interactions of the Internet and PSTN. Surveying the
implementations, we can make the following observations: The ICW service
plays the role of a benchmark service. All four implementations can
support ICW, with three specifically designed for it. Session Initiation
Protocol (SIP) is used in most of the implementations as the base
communications protocol between the PSTN and Internet. (NEC's
implementation is the only exception that uses a proprietary protocol.
Nevertheless, NEC has a plan to support SIP together with the extensions
for SPIRITS services.) All implementations use IN-based solutions for
the PSTN part. It is clear that not all pre-SPIRITS implementations
inter-operate with each other. It is also clear that not all SIP-based
implementations inter-operate with each other given that they do not
support the same version of SIP. It is a task of the SPIRITS Working
Group to define the inter-networking interfaces that will support
interoperation of the future implementations of SPIRITS services. This
document is a product of the Service in the PSTN/IN Requesting InTernet
Service Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2995.txt"
}

@TECHREPORT{rfc2996,
AUTHOR="Y. Bernet",
TITLE="Format of the {RSVP} {DCLASS} Object",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2996,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="Resource Reservation Protocol (RSVP) signaling may be used to
request Quality of Service (QoS) services and enhance the manageability
of application traffic's QoS in a differentiated service (diff-serv or
DS) network. When using RSVP with DS networks it is useful to be able to
carry carry Differentiated Services Code Points (DSCPs) in RSVP message
objects. One example of this is the use of RSVP to arrange for the
marking of packets with a particular DSCP upstream from the DS network's
ingress point, at the sender or at a previous network's egress router.
The DCLASS object is used to represent and carry DSCPs within RSVP
messages. This document specifies the format of the DCLASS object and
briefly discusses its use.",
URL="http://www.rfc-editor.org/rfc/rfc2996.txt"
}

@TECHREPORT{rfc2997,
AUTHOR="Y. Bernet and A. J. Smith and B. S. Davie",
TITLE="Specification of the Null Service Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2997,
PAGES=12,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="In the typical Resource Reservation Protocol (RSVP)/Intserv
model, applications request a specific Intserv service type and quantify
the resources required for that service. For certain applications, the
determination of service parameters is best left to the discretion of
the network administrator. For example, ERP applications are often
mission critical and require some form of prioritized service, but
cannot readily specify their resource requirements. To serve such
applications, we introduce the notion of the \'Null Service'. The Null
Service allows applications to identify themselves to network Quality of
Service (QoS) policy agents, using RSVP signaling. However, it does not
require them to specify resource requirements. QoS policy agents in the
network respond by applying QoS policies appropriate for the application
(as determined by the network administrator). This mode of RSVP usage is
particularly applicable to networks that combine differentiated service
(diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this
environment, QoS policy agents may direct the signaled application's
traffic to a particular diffserv class of service. This document is a
product of the Integrated Services over Specific Link Layers Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2997.txt"
}

@TECHREPORT{rfc2998,
AUTHOR="Y. Bernet and P. Ford and R. Yavatkar and F. Baker and L. Zhang and M.
Speer and R. Braden and B. S. Davie",
TITLE="A Framework for Integrated Services Operation over Diffserv Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2998,
PAGES=31,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="The Integrated Services (Intserv) architecture provides a
means for the delivery of end-to-end Quality of Service (QoS) to
applications over heterogeneous networks. To support this end-to-end
model, the Intserv architecture must be supported over a wide variety of
different types of network elements. In this context, a network that
supports Differentiated Services (Diffserv) may be viewed as a network
element in the total end-to-end path. This document describes a
framework by which Integrated Services may be supported over Diffserv
networks. This document is a product of the Integrated Services over
Specific Link Layers Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2998.txt"
}

@TECHREPORT{rfc3001,
AUTHOR="M. Mealling",
TITLE="A {URN} Namespace of Object Identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3001,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document describes a Uniform Resource Names (URN)
namespace that contains Object Identifiers (OIDs).",
URL="http://www.rfc-editor.org/rfc/rfc3001.txt"
}

@TECHREPORT{rfc3002,
AUTHOR="D. Mitzel",
TITLE="Overview of 2000 {IAB} Wireless Internetworking Workshop",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3002,
PAGES=42,
DAYS=15,
MONTH=dec,
YEAR=2000,
ABSTRACT="This document provides an overview of a workshop held by the
Internet Architecture Board (IAB) on wireless internetworking. The
workshop was hosted by Nokia in Mountain View, CA, USA on February 29
thru March 2, 2000. The goal of the workshop was to assess current and
future uses of Internet technology in wireless environments, to make
recommendations on research and standardization tasks to improve
acceptance of Internet network and transport protocols in wireless
environments, and to evaluate methods to improve communication and
collaboration among Internet standards working groups and those of the
telephony and wireless sectors. This report summarizes the conclusions
and recommendations of the IAB on behalf of the IETF community.",
URL="http://www.rfc-editor.org/rfc/rfc3002.txt"
}

@TECHREPORT{rfc3003,
AUTHOR="M. Nilsson",
TITLE="The audio/mpeg Media Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3003,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="The audio layers of the MPEG-1 and MPEG-2 standards are in
frequent use on the internet, but there is no uniform Multipurpose
Internet Mail Extension (MIME) type for these files. The intention of
this document is to define the media type audio/mpeg to refer to this
kind of contents.",
URL="http://www.rfc-editor.org/rfc/rfc3003.txt"
}

@TECHREPORT{rfc3004,
AUTHOR="G. Stump and R. E. Droms and Y. Gu and R. Vyaghrapuri and A. Demirtjis and
B. Beser and J. Privat",
TITLE="The User Class Option for {DHCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3004,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This option is used by a Dynamic Host Configuration Protocol
(DHCP) client to optionally identify the type or category of user or
applications it represents. The information contained in this option is
an opaque field that represents the user class of which the client is a
member. Based on this class, a DHCP server selects the appropriate
address pool to assign an address to the client and the appropriate
configuration parameters. This option should be configurable by a user.
This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3004.txt"
}

@TECHREPORT{rfc3005,
AUTHOR="S. J. Harris",
TITLE="{IETF} Discussion List Charter",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3005,
PAGES=3,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="The Internet Engineering Task Force (IETF) discussion mailing
list furthers the development and specification of Internet technology
through discussion of technical issues, and hosts discussions of IETF
direction, policy, meetings, and procedures. As this is the most general
IETF mailing list, considerable latitude is allowed. Advertising,
whether to solicit business or promote employment opportunities, falls
well outside the range of acceptable topics, as do discussions of a
personal nature.",
URL="http://www.rfc-editor.org/rfc/rfc3005.txt"
}

@TECHREPORT{rfc3006,
AUTHOR="B. S. Davie and C. Iturralde and D. Oran and S. Casner and J. Wroclawski",
TITLE="Integrated Services in the Presence of Compressible Flows",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3006,
PAGES=13,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="An Integrated Services (int-serv) router performs admission
control and resource allocation based on the information contained in a
TSpec (among other things). As currently defined, TSpecs convey
information about the data rate (using a token bucket) and range of
packet sizes of the flow in question. However, the TSpec may not be an
accurate representation of the resources needed to support the
reservation if the router is able to compress the data at the link
level. This specification describes an extension to the TSpec which
enables a sender of potentially compressible data to provide hints to
int-serv routers about the compressibility they may obtain. Routers
which support appropriate compression take advantage of the hint in
their admission control decisions and resource allocation procedures;
other routers ignore the hint. An initial application of this approach
is to notify routers performing real-time transport protocol (RTP)
header compression that they may allocate fewer resources to RTP flows.
This document is a product of the Integrated Services Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3006.txt"
}

@TECHREPORT{rfc3007,
AUTHOR="B. Wellington",
TITLE="Secure Domain Name System {(DNS)} Dynamic Update",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3007,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document proposes a method for performing secure Domain
Name System (DNS) dynamic updates. The method described here is intended
to be flexible and useful while requiring as few changes to the protocol
as possible. The authentication of the dynamic update message is
separate from later DNSSEC validation of the data. Secure communication
based on authenticated requests and transactions is used to provide
authorization.",
URL="http://www.rfc-editor.org/rfc/rfc3007.txt"
}

@TECHREPORT{rfc3008,
AUTHOR="B. Wellington",
TITLE="Domain Name System Security {(DNSSEC)} Signing Authority",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3008,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document proposes a revised model of Domain Name System
Security (DNSSEC) Signing Authority. The revised model is designed to
clarify earlier documents and add additional restrictions to simplify
the secure resolution process. Specifically, this affects the
authorization of keys to sign sets of records.",
URL="http://www.rfc-editor.org/rfc/rfc3008.txt"
}

@TECHREPORT{rfc3009,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="Registration of parityfec {MIME} types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3009,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="The RTP (Real-time Transport Protocol) payload format for
generic forward error correction allows RTP participants to improve loss
resiliency through the use of traditional parity-based channel codes.
This payload format requires four new MIME types, audio/parityfec,
video/parityfec, text/parityfec and application/parityfec. This document
serves as the MIME type registration for those formats.",
URL="http://www.rfc-editor.org/rfc/rfc3009.txt"
}

@TECHREPORT{rfc3010,
AUTHOR="S. Shepler and B. Callaghan and D. Robinson and R. Thurlow and C. Beame and
M. Eisler and D. Noveck",
TITLE="{NFS} version 4 Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3010,
PAGES=212,
DAYS=15,
MONTH=dec,
YEAR=2000,
ABSTRACT="NFS (Network File System) version 4 is a distributed file
system protocol which owes heritage to NFS protocol versions 2 [RFC1094]
and 3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol
supports traditional file access while integrating support for file
locking and the mount protocol. In addition, support for strong security
(and its negotiation), compound operations, client caching, and
internationalization have been added. Of course, attention has been
applied to making NFS version 4 operate well in an Internet environment.
This document is a product of the Network File System Version 4 Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3010.txt"
}

@TECHREPORT{rfc3011,
AUTHOR="G. Waters",
TITLE="The {IPv4} Subnet Selection Option for {DHCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3011,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This memo defines a new Dynamic Host Configuration Protocol
(DHCP) option for selecting the subnet on which to allocate an address.
This option would override a DHCP server's normal methods of selecting
the subnet on which to allocate an address for a client. This document
is a product of the Dynamic Host Configuration Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3011.txt"
}

@TECHREPORT{rfc3012,
AUTHOR="C. E. Perkins and P. Calhoun",
TITLE="Mobile {IPv4} {Challenge/Response} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3012,
PAGES=17,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="Mobile IP, as originally specified, defines an authentication
extension (the Mobile-Foreign Authentication extension) by which a
mobile node can authenticate itself to a foreign agent. Unfortunately,
this extension does not provide ironclad replay protection for the
foreign agent, and does not allow for the use of existing techniques
(such as CHAP) for authenticating portable computer devices. In this
specification, we define extensions for the Mobile IP Agent
Advertisements and the Registration Request that allow a foreign agent
to use a challenge/response mechanism to authenticate the mobile node.
This document is a product of the IP Routing for Wireless/Mobile Hosts
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3012.txt"
}

@TECHREPORT{rfc3013,
AUTHOR="T. Killalea",
TITLE="Recommended Internet Service Provider Security Services and Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3013,
PAGES=13,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="The purpose of this document is to express what the
engineering community as represented by the IETF expects of Internet
Service Providers (ISPs) with respect to security. It is not the intent
of this document to define a set of requirements that would be
appropriate for all ISPs, but rather to raise awareness among ISPs of
the community's expectations, and to provide the community with a
framework for discussion of security expectations with current and
prospective service providers. This document is a product of the
Guidelines and Recommendations for Security Incident Processing Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3013.txt"
}

@TECHREPORT{rfc3014,
AUTHOR="R. Kavasseri",
TITLE="Notification Log {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3014,
PAGES=26,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for logging
Simple Network Management Protocol (SNMP) Notifications. This document
is a product of the Distributed Management Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3014.txt"
}

@TECHREPORT{rfc3015,
AUTHOR="F. Cuervo and N. Greene and A. Rayhan and C. Huitema and B. Rosen and J.
Segers",
TITLE="Megaco Protocol Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3015,
PAGES=179,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document defines the protocol used between elements of a
physically decomposed multimedia gateway, i.e. a Media Gateway and a
Media Gateway Controller. The document is common text with ITU-T
Recommendation H.248 and is a result of applying the changes yin RFC
2886 to the text of RFC 2885. The protocol presented in this document
meets the requirements for a media gateway control protocol as presented
in RFC 2805. This document is a product of the Media Gateway Control
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3015.txt"
}

@TECHREPORT{rfc3016,
AUTHOR="Y. Kikuchi and T. Nomura and S. Fukunaga and Y. Matsui and H. Kimata",
TITLE="{RTP} Payload Format for {MPEG-4} {Audio/Visual} Streams",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3016,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=2000,
ABSTRACT="This document describes Real-Time Transport Protocol (RTP)
payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual
bitstreams without using MPEG-4 Systems. For the purpose of directly
mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides
specifications for the use of RTP header fields and also specifies
fragmentation rules. It also provides specifications for Multipurpose
Internet Mail Extensions (MIME) type registrations and the use of
Session Description Protocol (SDP). This document is a product of the
Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3016.txt"
}

@TECHREPORT{rfc3017,
AUTHOR="M. Riegel and G. Zorn",
TITLE="{XML} {DTD} for Roaming Access Phone Book",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3017,
PAGES=33,
DAYS=15,
MONTH=dec,
YEAR=2000,
ABSTRACT="This document defines the syntax as well as the semantics of
the information to be included in the phone book for roaming
applications. It comprises the information necessary to select the most
appropriate ISP and to configure the host to get access to the network
of the provider. The specification consists of a small set of required
information elements and a variety of possible extensions. All data is
specified in XML [5] (Extensible Markup Language) syntax leading to a
concise XML DTD (Document Type Declaration) for the phone book. This
document is a product of the Roaming Operations Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3017.txt"
}

@TECHREPORT{rfc3018,
AUTHOR="A. Bogdanov",
TITLE="Unified Memory Space Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3018,
PAGES=81,
DAYS=15,
MONTH=dec,
YEAR=2000,
ABSTRACT="This document specifies Unified Memory Space Protocol (UMSP),
which gives a capability of immediate access to memory of the remote
nodes.",
URL="http://www.rfc-editor.org/rfc/rfc3018.txt"
}

@TECHREPORT{rfc3020,
AUTHOR="P. Pate and B. Lynch and K. Rehbehn",
TITLE="Definitions of Managed Objects for Monitoring and Controlling the {UNI/NNI}
Multilink Frame Relay Function",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3020,
PAGES=36,
DAYS=15,
MONTH=dec,
YEAR=2000,
ABSTRACT="This memo defines a Management Information Base (MIB) for
monitoring and controlling a UNI/NNI Multilink Frame Relay Function as
defined in Frame Relay Forum FRF.16. This MIB also includes conformance
and notification information. This document is a product of the Frame
Relay Service MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3020.txt"
}

@TECHREPORT{rfc3021,
AUTHOR="A. Retana and R. White and V. Fuller and D. McPherson",
TITLE="Using 31-Bit Prefixes on {IPv4} {Point-to-Point} Links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3021,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=2000,
ABSTRACT="With ever-increasing pressure to conserve IP address space on
the Internet, it makes sense to consider where relatively minor changes
can be made to fielded practice to improve numbering efficiency. One
such change, proposed by this document, is to halve the amount of
address space assigned to point-to-point links (common throughout the
Internet infrastructure) by allowing the use of 31-bit subnet masks in a
very limited way.",
URL="http://www.rfc-editor.org/rfc/rfc3021.txt"
}

@TECHREPORT{rfc3030,
AUTHOR="G. M. Vaudreuil",
TITLE="{SMTP} Service Extensions for Transmission of Large and Binary {MIME}
Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3030,
PAGES=12,
DAYS=15,
MONTH=dec,
YEAR=2000,
ABSTRACT={This memo defines two extensions to the SMTP (Simple Mail
Transfer Protocol) service. The first extension enables a SMTP client
and server to negotiate the use of an alternative to the DATA command,
called {"}BDAT{"}, for efficiently sending large MIME (Multipurpose
Internet
Mail Extensions) messages. The second extension takes advantage of the
BDAT command to permit the negotiated sending of MIME messages that
employ the binary transfer encoding. This document is intended to update
and obsolete RFC 1830.},
URL="http://www.rfc-editor.org/rfc/rfc3030.txt"
}

@TECHREPORT{rfc2800,
AUTHOR="J. F. Reynolds and R. Braden and S. Ginoza and L. Shiota",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2800,
PAGES=38,
DAYS=15,
MONTH=may,
YEAR=2001,
ABSTRACT="This memo contains a snapshot of the state of standardization
of protocols used in the Internet as of April 17, 2001. It lists only
official protocol standards RFCs; it is not a complete index to the RFC
series. The latest version of this memo is designated STD 1.",
URL="http://www.rfc-editor.org/rfc/rfc2800.txt"
}

@TECHREPORT{rfc2821,
EDITOR="J. Klensin",
TITLE="Simple Mail Transfer Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2821,
PAGES=79,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="This document is a self-contained specification of the basic
protocol for the Internet electronic mail transport. It consolidates,
updates and clarifies, but doesn't add new or change existing
functionality of the following: the original SMTP (Simple Mail Transfer
Protocol) specification of RFC 821, domain name system requirements and
implications for mail transport from RFC 1035 and RFC 974, the
clarifications and applicability statements in RFC 1123, and material
drawn from the SMTP Extension mechanisms. It obsoletes RFC 821, RFC 974,
and updates RFC 1123 (replaces the mail transport materials of RFC
1123). However, RFC 821 specifies some features that were not in
significant use in the Internet by the mid-1990s and (in appendices)
some additional transport models. Those sections are omitted here in the
interest of clarity and brevity; readers needing them should refer to
RFC 821. It also includes some additional material from RFC 1123 that
required amplification. This material has been identified in multiple
ways, mostly by tracking flaming on various lists and newsgroups and
problems of unusual readings or interpretations that have appeared as
the SMTP extensions have been deployed. Where this specification moves
beyond consolidation and actually differs from earlier documents, it
supersedes them technically as well as textually. Although SMTP was
designed as a mail transport and delivery protocol, this specification
also contains information that is important to its use as a 'mail
submission' protocol, as recommended for POP and IMAP. Additional
submission issues are discussed in RFC 2476. Section 2.3 provides
definitions of terms specific to this document. Except when the
historical terminology is necessary for clarity, this document uses the
current 'client' and 'server' terminology to identify the sending and
receiving SMTP processes, respectively. A companion document discusses
message headers, message bodies and formats and structures for them, and
their relationship. This document is a product of the Detailed
Revision/Update of Message Standards Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc2821.txt"
}

@TECHREPORT{rfc2822,
EDITOR="Paul  Resnick",
TITLE="Internet Message Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2822,
PAGES=51,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT={This standard specifies a syntax for text messages that are
sent between computer users, within the framework of {"}electronic mail{"}
messages. This standard supersedes the one specified in Request For
Comments (RFC) 822, {"}Standard for the Format of ARPA Internet Text
Messages{"}, updating it to reflect current practice and incorporating
incremental changes that were specified in other RFCs. This document is
a product of the Detailed Revision/Update of Message Standards Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc2822.txt"
}

@TECHREPORT{rfc2899,
AUTHOR="S. Ginoza",
TITLE="Request for Comments Summary {RFC} Numbers {2800-2899}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2899,
PAGES=22,
DAYS=15,
MONTH=may,
YEAR=2001,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
2800 through RFCs 2899. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2899.txt"
}

@TECHREPORT{rfc2919,
AUTHOR="R. Chandhok and G. Wenger",
TITLE="{List-Id:} A Structured Field and Namespace for the Identification of
Mailing Lists",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2919,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="Software that handles electronic mailing list messages
(servers and user agents) needs a way to reliably identify messages that
belong to a particular mailing list. With the advent of list management
headers, it has become even more important to provide a unique
identifier for a mailing list regardless of the particular host that
serves as the list processor at any given time. The List-Id header
provides a standard location for such an identifier. In addition, a
namespace for list identifiers based on fully qualified domain names is
described. This namespace is intended to guarantee uniqueness for list
owners who require it, while allowing for a less rigorous namespace for
experimental and personal use. By including the List-Id field, list
servers can make it easier for mail clients to provide automated tools
for users to perform list functions. The list identifier can serve as a
key to make many automated processing tasks easier, and hence more
widely available.",
URL="http://www.rfc-editor.org/rfc/rfc2919.txt"
}

@TECHREPORT{rfc2961,
AUTHOR="L. Berger and D. Gan and G. Swallow and P. Pan and F. Tommasi and S.
Molendini",
TITLE="{RSVP} Refresh Overhead Reduction Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2961,
PAGES=34,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="This document describes a number of mechanisms that can be
used to reduce processing overhead requirements of refresh messages,
eliminate the state synchronization latency incurred when an RSVP
(Resource ReserVation Protocol) message is lost and, when desired,
refreshing state without the transmission of whole refresh messages. The
same extensions also support reliable RSVP message delivery on a per hop
basis. These extension present no backwards compatibility issues.",
URL="http://www.rfc-editor.org/rfc/rfc2961.txt"
}

@TECHREPORT{rfc2999,
AUTHOR="S. Ginoza",
TITLE="Request for Comments Summary {RFC} Numbers {2900-2999}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=2999,
PAGES=23,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
2900 through RFCs 2999. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc2999.txt"
}

@TECHREPORT{rfc3019,
AUTHOR="B. Haberman and R. Worzella",
TITLE="{IP} Version 6 Management Information Base for The Multicast Listener
Discovery Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3019,
PAGES=15,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document defines a portion of the Management Information
Base (MIB) for use with network management protocols in Internet
Protocol Version 6 internets. Specifically, this document is the MIB
module that defines managed objects for implementations of the Multicast
Listener Discovery Protocol. This document is a product of the IPNG
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3019.txt"
}

@TECHREPORT{rfc3022,
AUTHOR="P. Srisuresh and K. Egevang",
TITLE="Traditional {IP} Network Address Translator (Traditional {NAT)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3022,
PAGES=16,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="Basic Network Address Translation or Basic NAT is a method by
which IP addresses are mapped from one group to another, transparent to
end users. Network Address Port Translation, or NAPT is a method by
which many network addresses and their TCP/UDP (Transmission Control
Protocol/User Datagram Protocol) ports are translated into a single
network address and its TCP/UDP ports. Together, these two operations,
referred to as traditional NAT, provide a mechanism to connect a realm
with private addresses to an external realm with globally unique
registered addresses. This document is a product of the Network Access
Translators Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3022.txt"
}

@TECHREPORT{rfc3023,
AUTHOR="M. Murata and S. St. Laurent and D. Kohn",
TITLE="{XML} Media Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3023,
PAGES=39,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT={This document standardizes five new media types -- text/xml,
application/xml, text/xml-external-parsed-entity,
application/xml-external-parsed-entity, and application/xml-dtd -- for
use in exchanging network entities that are related to the Extensible
Markup Language (XML). This document also standardizes a convention
(using the suffix '+xml') for naming media types outside of these five
types when those media types represent XML MIME (Multipurpose Internet
Mail Extensions) entities. XML MIME 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. Major differences from RFC 2376 are (1)
the addition of text/xml-external-parsed-entity,
application/xml-external-parsed-entity, and application/xml-dtd, (2) the
'+xml' suffix convention (which also updates the RFC 2048 registration
process), and (3) the discussion of {"}utf-16le{"} and {"}utf-16be{"}.},
URL="http://www.rfc-editor.org/rfc/rfc3023.txt"
}

@TECHREPORT{rfc3024,
EDITOR="Gabriel E. Montenegro",
TITLE="Reverse Tunneling for Mobile {IP,} revised",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3024,
PAGES=30,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="Mobile Internet Protocol (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. This document proposes backwards-compatible extensions to
Mobile IP 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.
This document obsoletes RFC 2344. This document is a product of the IP
Routing for Wireless/Mobile Hosts Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3024.txt"
}

@TECHREPORT{rfc3025,
AUTHOR="G. Dommety and K. K. Leung",
TITLE="Mobile {IP} {Vendor/Organization-Specific} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3025,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This document defines two new extensions to Mobile IP. These
extensions will facilitate equipment vendors and organizations to make
specific use of these extensions as they see fit for research or
deployment purposes. This document is a product of the IP Routing for
Wireless/Mobile Hosts Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3025.txt"
}

@TECHREPORT{rfc3026,
AUTHOR="R. Blane",
TITLE="Liaison to {IETF/ISOC} on {ENUM}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3026,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT={Working Party 1/2, of the International Telecommunication
Union Telecommunication Standardization Sector (ITU-T) held a meeting of
its collaborators in Berlin Germany 19-26 October 2000. The agenda of
the meeting contained several contributions regarding RFC 2916: {"}E.164
Number and DNS{"} from the Internet Engineering Task Force's (IETF) ENUM
Working Group - more specifically, the method for administering and
maintaining the E.164-based resources in the Domain Name System (DNS) as
related to the ENUM protocol. Consequently, in addition to the WP1/2
collaborators, there were several members of the IETF present to assist
with the discussion of issues contained in the aforementioned
contributions. This liaison from WP1/2 to the IETF/ISOC conveys the
understandings of the WP1/2 collaborators resulting from the
discussions.},
URL="http://www.rfc-editor.org/rfc/rfc3026.txt"
}

@TECHREPORT{rfc3027,
AUTHOR="M. Holdrege and P. Srisuresh",
TITLE="Protocol Complications with the {IP} Network Address Translator",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3027,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="Many internet applications can be adversely affected when end
nodes are not in the same address realm and seek the assistance of an IP
Network Address Translator (NAT) enroute to bridge the realms. The NAT
device alone cannot provide the necessary application/protocol
transparency in all cases and seeks the assistance of Application Level
Gateways (ALGs) where possible, to provide transparency. The purpose of
this document is to identify the protocols and applications that break
with NAT enroute. The document also attempts to identify any known
workarounds. It is not possible to capture all applications that break
with NAT in a single document. This document attempts to capture as much
information as possible, but is by no means a comprehensive coverage. We
hope the coverage provides sufficient clues for applications not
covered. This document is a product of the Network Address Translators
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3027.txt"
}

@TECHREPORT{rfc3028,
AUTHOR="T. Showalter",
TITLE="Sieve: A Mail Filtering Language",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3028,
PAGES=36,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document describes a language for filtering e-mail
messages at time of final delivery. It is designed to be implementable
on either a mail client or mail server. It is meant to be extensible,
simple, and independent of access protocol, mail architecture, and
operating system. It is suitable for running on a mail server where
users may not be allowed to execute arbitrary programs, such as on black
box Internet Message Access Protocol (IMAP) servers, as it has no
variables, loops, or ability to shell out to external programs.",
URL="http://www.rfc-editor.org/rfc/rfc3028.txt"
}

@TECHREPORT{rfc3029,
AUTHOR="C. J. Adams and P. Sylvester and M. Zolotarev and R. Zuccherato",
TITLE="Internet {X.509} Public Key Infrastructure Data Validation and
Certification Server Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3029,
PAGES=51,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This document describes a general Data Validation and
Certification Server (DVCS) and the protocols to be used when
communicating with it. The Data Validation and Certification Server is a
Trusted Third Party (TTP) that can be used as one component in building
reliable non-repudiation services. Useful Data Validation and
Certification Server responsibilities in a PKI are to assert the
validity of signed documents, public key certificates, and the
possession or existence of data. Assertions created by this protocol are
called Data Validation Certificates (DVC). We give examples of how to
use the Data Validation and Certification Server to extend the lifetime
of a signature beyond key expiry or revocation and to query the Data
Validation and Certification Server regarding the status of a public key
certificate. The document includes a complete example of a time stamping
transaction.",
URL="http://www.rfc-editor.org/rfc/rfc3029.txt"
}

@TECHREPORT{rfc3031,
AUTHOR="E. C. Rosen and A. Viswanathan and R. Callon",
TITLE="Multiprotocol Label Switching Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3031,
PAGES=61,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document specifies the architecture for Multiprotocol
Label Switching (MPLS). This document is a product of the Multiprotocol
Label Switching Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3031.txt"
}

@TECHREPORT{rfc3032,
AUTHOR="E. C. Rosen and D. C. Tappan and G. Fedorkow and Y. Rekhter and D.
Farinacci and T. Li and A. Conta",
TITLE="{MPLS} Label Stack Encoding",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3032,
PAGES=23,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT={{"}Multi-Protocol Label Switching (MPLS){"} requires a set of
procedures for augmenting network layer packets with {"}label stacks{"},
thereby turning them into {"}labeled packets{"}. Routers which support MPLS
are known as {"}Label Switching Routers{"}, or {"}LSRs{"}. In order to
transmit
a labeled packet on a particular data link, an LSR must support an
encoding technique which, given a label stack and a network layer
packet, produces a labeled packet. This document specifies the encoding
to be used by an LSR in order to transmit labeled packets on
Point-to-Point Protocol (PPP) data links, on LAN data links, and
possibly on other data links as well. On some data links, the label at
the top of the stack may be encoded in a different manner, but the
techniques described here MUST be used to encode the remainder of the
label stack. This document also specifies rules and procedures for
processing the various fields of the label stack encoding. This document
is a product of the Multiprotocol Label Switching Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3032.txt"
}

@TECHREPORT{rfc3033,
AUTHOR="M. Suzuki",
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",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3033,
PAGES=25,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="The purpose of this document is to specify 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.
The assignment, that is specified in section 4 of this document, is
designed for advanced B-ISDN signaling support of the Internet protocol,
especially the B-ISDN signaling support for the connection that
corresponds to the session in the Internet protocol which is clarified
in section 2. This specification provides an indispensable framework for
the implementation of long-lived session and QoS-sensitive session
transfers over ATM. This document is a product of the Multiprotocol
Label Switching Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3033.txt"
}

@TECHREPORT{rfc3034,
AUTHOR="A. Conta and P. Doolan and A. Malis",
TITLE="Use of Label Switching on Frame Relay Networks Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3034,
PAGES=24,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document defines the model and generic mechanisms for
Multiprotocol Label Switching on Frame Relay networks. Furthermore, it
extends and clarifies portions of the Multiprotocol Label Switching
Architecture described in [ARCH] and the Label Distribution Protocol
(LDP) described in [LDP] relative to Frame Relay Networks. MPLS enables
the use of Frame Relay Switches as Label Switching Routers (LSRs). This
document is a product of the Multiprotocol Label Switching Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3034.txt"
}

@TECHREPORT{rfc3035,
AUTHOR="B. S. Davie and J. Lawrence and K. McCloghrie and E. C. Rosen and G.
Swallow and Y. Rekhter and P. Doolan",
TITLE="{MPLS} using {LDP} and {ATM} {VC} Switching",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3035,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="The Multiprotocol Label Switching (MPLS) Architecture
discusses a way in which Asynchronous Transfer Mode (ATM) switches may
be used as Label Switching Routers. The ATM switches run network layer
routing algorithms (such as Open Shortest Path First (OSPF),
Intermediate System to Intermediate System (IS-IS), etc.), and their
data forwarding is based on the results of these routing algorithms. No
ATM-specific routing or addressing is needed. ATM switches used in this
way are known as ATM-LSRs (Label Switching Routers). This document
extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by
specifying in more detail the procedures which to be used when
distributing labels to or from ATM-LSRs, when those labels represent
Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes
are determined on a hop-by-hop basis by network layer routing
algorithms. This document also specifies the MPLS encapsulation to be
used when sending labeled packets to or from ATM-LSRs, and in that
respect is a companion document to RFC 3032.",
URL="http://www.rfc-editor.org/rfc/rfc3035.txt"
}

@TECHREPORT{rfc3036,
AUTHOR="L. Andersson and P. Doolan and N. E. Feldman and A. Fredette and B. Thomas",
TITLE="{LDP} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3036,
PAGES=132,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="The architecture for Multi Protocol Label Switching (MPLS) is
described in RFC 3031. A fundamental concept in MPLS is that two Label
Switching Routers (LSRs) must agree on the meaning of the labels used to
forward traffic between and through them. This common understanding is
achieved by using a set of procedures, called a label distribution
protocol, by which one LSR informs another of label bindings it has
made. This document defines a set of such procedures called LDP (for
Label Distribution Protocol) by which LSRs distribute labels to support
MPLS forwarding along normally routed paths. This document is a product
of the Multiprotocol Label Switching Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3036.txt"
}

@TECHREPORT{rfc3037,
AUTHOR="B. Thomas and E. Gray",
TITLE="{LDP} Applicability",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3037,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="Multiprotocol Label Switching (MPLS) is a method for
forwarding packets that uses short, fixed-length values carried by
packets, called labels, to determine packet nexthops. A fundamental
concept in MPLS is that two Label Switching Routers (LSRs) must agree on
the meaning of the labels used to forward traffic between and through
them. This common understanding is achieved by using a set of
procedures, called a label distribution protocol, by which one LSR
informs another of label bindings it has made. This document describes
the applicability of a set of such procedures called LDP (for Label
Distribution Protocol) by which LSRs distribute labels to support MPLS
forwarding along normally routed paths. This document is a product of
the Multiprotocol Label Switching Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3037.txt"
}

@TECHREPORT{rfc3038,
AUTHOR="K. Nagami and Y. Katsube and N. Demizu and H. Esaki and P. Doolan",
TITLE="{VCID} Notification over {ATM} link for {LDP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3038,
PAGES=19,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="The Asynchronous Transfer Mode Label Switching Router
(ATM-LSR) is one of the major applications of label switching. Because
the ATM layer labels (VPI and VCI) associated with a VC rewritten with
new value at every ATM switch nodes, it is not possible to use them to
identify a VC in label mapping messages. The concept of Virtual
Connection Identifier (VCID) is introduced to solve this problem. VCID
has the same value at both ends of a VC. This document specifies the
procedures for the communication of VCID values between neighboring
ATM-LSRs that must occur in order to ensure this property. This document
is a product of the Multiprotocol Label Switching Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3038.txt"
}

@TECHREPORT{rfc3039,
AUTHOR="S. Santesson and W. Polk and P. Barzin and M. Nystrom",
TITLE="Internet {X.509} Public Key Infrastructure Qualified Certificates Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3039,
PAGES=35,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document forms a certificate profile for Qualified
Certificates, based on RFC 2459, for use in the Internet. The term
Qualified Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons. The goal of
this document is to define a general syntax independent of local legal
requirements. The profile is however designed to allow further profiling
in order to meet specific local needs. It is important to note that the
profile does not define any legal requirements for Qualified
Certificates. This document is a product of the Public-Key
Infrastructure (X.509) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3039.txt"
}

@TECHREPORT{rfc3040,
AUTHOR="I. Cooper and I. Melve and G. Tomlinson",
TITLE="Internet Web Replication and Caching Taxonomy",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3040,
PAGES=32,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT={This memo specifies standard terminology and the taxonomy of
web replication and caching infrastructure as deployed today. It
introduces standard concepts, and protocols used today within this
application domain. Currently deployed solutions employing these
technologies are presented to establish a standard taxonomy. Known
problems with caching proxies are covered in the document titled {"}Known
HTTP Proxy/Caching Problems{"}, and are not part of this document. This
document presents open protocols and points to published material for
each protocol. This document is a product of the Web Replication and
Caching Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3040.txt"
}

@TECHREPORT{rfc3041,
AUTHOR="T. Narten and R. Draves",
TITLE="Privacy Extensions for Stateless Address Autoconfiguration in {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3041,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="Nodes use IPv6 stateless address autoconfiguration to generate
addresses without the necessity of a Dynamic Host Configuration Protocol
(DHCP) server. Addresses are formed by combining network prefixes with
an interface identifier. On interfaces that contain embedded IEEE
Identifiers, the interface identifier is typically derived from it. On
other interface types, the interface identifier is generated through
other means, for example, via random number generation. This document
describes an extension to IPv6 stateless address autoconfiguration for
interfaces whose interface identifier is derived from an IEEE
identifier. Use of the extension causes nodes to generate global-scope
addresses from interface identifiers that change over time, even in
cases where the interface contains an embedded IEEE identifier. Changing
the interface identifier (and the global-scope addresses generated from
it) over time makes it more difficult for eavesdroppers and other
information collectors to identify when different addresses used in
different transactions actually correspond to the same node. This
document is a product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3041.txt"
}

@TECHREPORT{rfc3042,
AUTHOR="M. Allman and H. Balakrishnan and S. Floyd",
TITLE="Enhancing {TCP's} Loss Recovery Using Limited Transmit",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3042,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT={This document proposes a new Transmission Control Protocol
(TCP) mechanism that can be used to more effectively recover lost
segments when a connection's congestion window is small, or when a large
number of segments are lost in a single transmission window. The
{"}Limited Transmit{"} algorithm calls for sending a new data segment in
response to each of the first two duplicate acknowledgments that arrive
at the sender. Transmitting these segments increases the probability
that TCP can recover from a single lost segment using the fast
retransmit algorithm, rather than using a costly retransmission timeout.
Limited Transmit can be used both in conjunction with, and in the
absence of, the TCP selective acknowledgment (SACK) mechanism. This
document is a product of the Transport Area Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3042.txt"
}

@TECHREPORT{rfc3043,
AUTHOR="M. Mealling",
TITLE="The Network Solutions Personal Internet Name {(PIN):} A {URN} Namespace for
People and Organizations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3043,
PAGES=5,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document describes a Uniform Resource Name (URN)
namespace that is engineered by Network Solutions, Inc. for naming
people and organizations.",
URL="http://www.rfc-editor.org/rfc/rfc3043.txt"
}

@TECHREPORT{rfc3044,
AUTHOR="S. Rozenfeld",
TITLE="Using The {ISSN} (International Serial Standard Number) as {URN} (Uniform
Resource Names) within an {ISSN-URN} Namespace",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3044,
PAGES=15,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT={This document presents how the ISSN - International Standard
Serial Number - which is a persistent number for unique identification
of serials widely recognised and used in the bibliographic world, can be
supported within the Uniform Resource Name (URN) framework as a specific
URN namespace identifier. An ISSN URN resolution system using the ISSN
identifier as Uniform resource Name within an ISN URN Namespace has been
developed by the ISSN International Centre (ISSN-IC) and is operating as
a demonstrator to evaluate all requirements to deploy it in an
operational environment. This proceeds from concepts and proposals
developed in several IETF RFCs emphasising the way to implement and to
use {"}recognised{"} existing numbering system within the URN framework
(RFC
2248, RFC 2141, RFC 2611).},
URL="http://www.rfc-editor.org/rfc/rfc3044.txt"
}

@TECHREPORT{rfc3045,
AUTHOR="M. Meredith",
TITLE="Storing Vendor Information in the {LDAP} root {DSE}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3045,
PAGES=6,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document specifies two Lightweight Directory Access
Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be
included in the root DSA-specific Entry (DSE) to advertise
vendor-specific information. These two attributes supplement the
attributes defined in section 3.4 of RFC 2251. The information held in
these attributes MAY be used for display and informational purposes and
MUST NOT be used for feature advertisement or discovery.",
URL="http://www.rfc-editor.org/rfc/rfc3045.txt"
}

@TECHREPORT{rfc3046,
AUTHOR="M. Patrick",
TITLE="{DHCP} Relay Agent Information Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3046,
PAGES=14,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT={Newer high-speed public Internet access technologies call for
a high-speed modem to have a local area network (LAN) attachment to one
or more customer premise hosts. It is advantageous to use the Dynamic
Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign
customer premise host IP addresses in this environment. However, a
number of security and scaling problems arise with such {"}public{"} DHCP
use. This document describes a new DHCP option to address these issues.
This option extends the set of DHCP options as defined in RFC 2132. The
new option is called the Relay Agent Information option and is inserted
by the DHCP relay agent when forwarding client-originated DHCP packets
to a DHCP server. Servers recognizing the Relay Agent Information option
may use the information to implement IP address or other parameter
assignment policies. The DHCP Server echoes the option back verbatim to
the relay agent in server-to-client replies, and the relay agent strips
the option before forwarding the reply to the client. The {"}Relay Agent
Information{"} option is organized as a single DHCP option that contains
one or more {"}sub-options{"} that convey information known by the relay
agent. The initial sub-options are defined for a relay agent that is
co-located in a public circuit access unit. These include a {"}circuit
ID{"}
for the incoming circuit, and a {"}remote ID{"} which provides a trusted
identifier for the remote high-speed modem. This document is a product
of the Dynamic Host Configuration Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3046.txt"
}

@TECHREPORT{rfc3047,
AUTHOR="P. Luthi",
TITLE="{RTP} Payload Format for {ITU-T} Recommendation {G.722.1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3047,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="International Telecommunication Union (ITU-T) Recommendation
G.722.1 is a wide-band audio codec, which operates at one of two
selectable bit rates, 24kbit/s or 32kbit/s. This document describes the
payload format for including G.722.1 generated bit streams within an RTP
packet. Also included here are the necessary details for the use of
G.722.1 with MIME and SDP. This document is a product of the Audio/Video
Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3047.txt"
}

@TECHREPORT{rfc3048,
AUTHOR="B. Whetten and L. Vicisano and R. Kermode and M. Handley and S. Floyd and
M. Luby",
TITLE="Reliable Multicast Transport Building Blocks for {One-to-Many} {Bulk-Data}
Transfer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3048,
PAGES=20,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT={This document describes a framework for the standardization of
bulk-data reliable multicast transport. It builds upon the experience
gained during the deployment of several classes of contemporary reliable
multicast transport, and attempts to pull out the commonalities between
these classes of protocols into a number of building blocks. To that
end, this document recommends that certain components that are common to
multiple protocol classes be standardized as {"}building blocks{"}. The
remaining parts of the protocols, consisting of highly protocol
specific, tightly intertwined functions, shall be designated as
{"}protocol cores{"}. Thus, each protocol can then be constructed by
merging
a {"}protocol core{"} with a number of {"}building blocks{"} which can be
re-used across multiple protocols. This document is a product of the
Reliable Multicast Transport Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3048.txt"
}

@TECHREPORT{rfc3049,
AUTHOR="J. Naugle and K. Kasthurirangan and G. Ledford",
TITLE="{TN3270E} Service Location and Session Balancing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3049,
PAGES=21,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document discusses the implementation of Service Location
Protocol (SLP) and session balancing with a TN3270E emulator in a client
server implementation with a TN3270E server. Application program
developer's can locate TN3270E services and load balance among those
services (3270 host sessions), by using this SLP support.",
URL="http://www.rfc-editor.org/rfc/rfc3049.txt"
}

@TECHREPORT{rfc3050,
AUTHOR="J. Lennox and Henning Schulzrinne and J. Rosenberg",
TITLE="Common Gateway Interface for {SIP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3050,
PAGES=35,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="In Internet telephony, there must be a means by which new
services are created and deployed rapidly. In the World Wide Web, the
Common Gateway Interface (CGI) has served as popular means towards
programming web services. Due to the similarities between the Session
Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP),
CGI is a good candidate for service creation in a SIP environment. This
document defines a SIP CGI interface for providing SIP services on a SIP
server.",
URL="http://www.rfc-editor.org/rfc/rfc3050.txt"
}

@TECHREPORT{rfc3051,
AUTHOR="J. R. Heath and J. Border",
TITLE="{IP} Payload Compression Using {ITU-T} {V.44} Packet Method",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3051,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document describes a compression method based on the data
compression algorithm described in International Telecommunication Union
(ITU-T) Recommendation V.44. Recommendation V.44 is a modem standard but
Annex B, Clause B.1, of the recommendation describes the implementation
of V.44 in packet networks (e.g., V.44 Packet Method). This document
defines the application of V.44 Packet Method to the Internet Protocol
(IP) Payload Compression Protocol (RFC 2393). RFC 2393 defines a method
for applying lossless compression to the payload portion of IP
datagrams. V.44 Packet Method is based upon the LZJH data compression
algorithm. Throughout the remainder of this document the terms V.44
Packet Method and LZJH are synonymous.",
URL="http://www.rfc-editor.org/rfc/rfc3051.txt"
}

@TECHREPORT{rfc3052,
AUTHOR="M. Eder and S. Nag",
TITLE="Service Management Architectures Issues and Review",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3052,
PAGES=12,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="Many of the support functions necessary to exploit the
mechanisms by which differing levels of service can be provided are
limited in scope and a complete framework is non-existent. Various
efforts at such a framework have received a great deal of attention and
represent a historical shift in scope for many of the organizations
looking to address this problem. The purpose of this document is to
explore the problems of defining a Service management framework and to
examine some of the issues that still need to be resolved.",
URL="http://www.rfc-editor.org/rfc/rfc3052.txt"
}

@TECHREPORT{rfc3053,
AUTHOR="A. Durand and P. Fasano and I. Guardini and D. Lento",
TITLE="{IPv6} Tunnel Broker",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3053,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="The IPv6 global Internet as of today uses a lot of tunnels
over the existing IPv4 infrastructure. Those tunnels are difficult to
configure and maintain in a large scale environment. The 6bone has
proven that large sites and Internet Service Providers (ISPs) can do it,
but this process is too complex for the isolated end user who already
has an IPv4 connection and would like to enter the IPv6 world. The
motivation for the development of the tunnel broker model is to help
early IPv6 adopters to hook up to an existing IPv6 network (e.g., the
6bone) and to get stable, permanent IPv6 addresses and DNS names. The
concept of the tunnel broker was first presented at Orlando's IETF in
December 1998. Two implementations were demonstrated during the Grenoble
IPng \& NGtrans interim meeting in February 1999.",
URL="http://www.rfc-editor.org/rfc/rfc3053.txt"
}

@TECHREPORT{rfc3054,
AUTHOR="P. Blatherwick and R. Bell and P. Holland",
TITLE="Megaco {IP} Phone Media Gateway Application Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3054,
PAGES=14,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document specifies a particular application of the
Megaco/H.248 Protocol for control of Internet telephones and similar
appliances: the Megaco IP Phone Media Gateway. The telephone itself is a
Media Gateway (MG), controlled by the Megaco/H.248 Protocol, with
application control intelligence located in the Media Gateway Controller
(MGC). To achieve a high degree of interoperability and design
efficiency in such end-user devices, a consistent architectural
approach, a particular organization of Terminations and Packages, and a
Protocol Profile are described. The approach makes use of existing
Protocol features and user interface related Packages, and is thus a
straight-forward application of the Megaco/H.248 Protocol. This document
is a product of the Media Gateway Control Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3054.txt"
}

@TECHREPORT{rfc3055,
AUTHOR="M. Krishnaswamy and D. Romascanu",
TITLE="Management Information Base for the {PINT} Services Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3055,
PAGES=21,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This memo describes a proposed Management Information Base
(MIB) for the PSTN/Internet Interworking (PINT) Services Architecture.
This document is a product of the PSTN and Internet Internetworking
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3055.txt"
}

@TECHREPORT{rfc3056,
AUTHOR="B. E. Carpenter and K. Moore",
TITLE="Connection of {IPv6} Domains via {IPv4} Clouds",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3056,
PAGES=23,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This memo specifies an optional interim mechanism for IPv6
sites to communicate with each other over the IPv4 network without
explicit tunnel setup, and for them to communicate with native IPv6
domains via relay routers. Effectively it treats the wide area IPv4
network as a unicast point-to-point link layer. The mechanism is
intended as a start-up transition tool used during the period of
co-existence of IPv4 and IPv6. It is not intended as a permanent
solution. The document defines a method for assigning an interim unique
IPv6 address prefix to any site that currently has at least one globally
unique IPv4 address, and specifies an encapsulation mechanism for
transmitting IPv6 packets using such a prefix over the global IPv4
network. The motivation for this method is to allow isolated IPv6
domains or hosts, attached to an IPv4 network which has no native IPv6
support, to communicate with other such IPv6 domains or hosts with
minimal manual configuration, before they can obtain natuve IPv6
connectivity. It incidentally provides an interim globally unique IPv6
address prefix to any site with at least one globally unique IPv4
address, even if combined with an IPv4 Network Address Translator (NAT).
This document is a product of the Next Generation Transition Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3056.txt"
}

@TECHREPORT{rfc3057,
AUTHOR="K. Morneault and S. Rengasami and M. Kalla and G. Sidebottom",
TITLE="{ISDN} {Q.921-User} Adaptation Layer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3057,
PAGES=66,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This document defines a protocol for backhauling of ISDN Q.921
User messages over IP using the Stream Control Transmission Protocol
(SCTP). This protocol would be used between a Signaling Gateway (SG) and
Media Gateway Controller (MGC). It is assumed that the SG receives ISDN
signaling over a standard ISDN interface. This document is a product of
the Signaling Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3057.txt"
}

@TECHREPORT{rfc3058,
AUTHOR="S. Teiwes and P. Hartmann and D. Kuenzi",
TITLE="Use of the {IDEA} Encryption Algorithm in {CMS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3058,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This memo specifies how to incorporate International Data
Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong
algorithm for symmetric encryption. For organizations who make use of
IDEA for data security purposes it is of high interest that IDEA is also
available in S/MIME. The intention of this memo is to provide the OIDs
and algorithms required that IDEA can be included in S/MIME for
symmetric content and key encryption. This document is a product of the
S/MIME Mail Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3058.txt"
}

@TECHREPORT{rfc3059,
AUTHOR="E. Guttman",
TITLE="Attribute List Extension for the Service Location Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3059,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="The Service Location Protocol, Version 2 (SLPv2) provides a
mechanism for a service to be discovered in a single exchange of
messages. This exchange of messages does not presently include any of
the service's attributes. This document specifies a SLPv2 extension
which allows a User Agent (UA) to request a service's attributes be
included as an extension to Service Reply messages. This will eliminate
the need for multiple round trip messages for a UA to acquire all
service information.",
URL="http://www.rfc-editor.org/rfc/rfc3059.txt"
}

@TECHREPORT{rfc3060,
AUTHOR="B. W. Moore and E. Ellesson and J. Strassner and A. Westerinen",
TITLE="Policy Core Information Model {--} Version 1 Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3060,
PAGES=100,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This document presents the object-oriented information model
for representing policy information developed jointly in the IETF Policy
Framework WG and as extensions to the Common Information Model (CIM)
activity in the Distributed Management Task Force (DMTF). This model
defines two hierarchies of object classes: structural classes
representing policy information and control of policies, and association
classes that indicate how instances of the structural classes are
related to each other. Subsequent documents will define mappings of this
information model to various concrete implementations, for example, to a
directory that uses LDAPv3 as its access protocol. This document is a
product of the Policy Framework Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3060.txt"
}

@TECHREPORT{rfc3061,
AUTHOR="M. Mealling",
TITLE="A {URN} Namespace of Object Identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3061,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This document describes a Uniform Resource Name (URN)
namespace that contains Object Identifiers (OIDs). It obsoletes RFC
3001.",
URL="http://www.rfc-editor.org/rfc/rfc3061.txt"
}

@TECHREPORT{rfc3062,
AUTHOR="K. Zeilenga",
TITLE="{LDAP} Password Modify Extended Operation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3062,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="The integration of the Lightweight Directory Access Protocol
(LDAP) and external authentication services has introduced non-DN
authentication identities and allowed for non-directory storage of
passwords. As such, mechanisms which update the directory (e.g., Modify)
cannot be used to change a user's password. This document describes an
LDAP extended operation to allow modification of user passwords which is
not dependent upon the form of the authentication identity nor the
password storage mechanism used.",
URL="http://www.rfc-editor.org/rfc/rfc3062.txt"
}

@TECHREPORT{rfc3063,
AUTHOR="Y. Ohba and Y. Katsube and E. C. Rosen and P. Doolan",
TITLE="{MPLS} Loop Prevention Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3063,
PAGES=44,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT={This paper presents a simple mechanism, based on {"}threads{"},
which can be used to prevent Multiprotocol Label Switching (MPLS) from
setting up label switched path (LSPs) which have loops. The mechanism is
compatible with, but does not require, VC merge. The mechanism can be
used with either the ordered downstream-on-demand allocation or ordered
downstream allocation. The amount of information that must be passed in
a protocol message is tightly bounded (i.e., no path-vector is used).
When a node needs to change its next hop, a distributed procedure is
executed, but only nodes which are downstream of the change are
involved. This document is a product of the Multiprotocol Label
Switching Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3063.txt"
}

@TECHREPORT{rfc3064,
AUTHOR="B. Foster",
TITLE="{MGCP} {CAS} Packages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3064,
PAGES=56,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT={This document contains a collection of media gateway Channel
Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS
PBX interconnect as well as basic FXO support. Included are six
packages. The {"}MS{"} package covers MF single stage dialing trunks. This
includes wink start and immediate start PBX DID/DOD trunks as well as
basic R1 and Feature Group D (FGD) Terminating protocol [3]. The {"}DT{"}
package covers immediate start and basic DTMF and dial-pulse trunks and
the {"}BL{"} package covers the interface to a basic PBX (digital or FXS
interface). In addition to the Terminating protocol, there are three
other FGD protocols described in [3]. These include EAIN and EANA which
is covered by the enclosed {"}MD{"} package and the Operator Service
Signaling protocol which is handled by the {"}MO{"} package. Support for
basic FXO interconnect is provided by {"}DO{"} package.},
URL="http://www.rfc-editor.org/rfc/rfc3064.txt"
}

@TECHREPORT{rfc3065,
AUTHOR="P. Traina and D. McPherson and J. Scudder",
TITLE="Autonomous System Confederations for {BGP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3065,
PAGES=11,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT={The Border Gateway Protocol (BGP) is an inter-autonomous
system routing protocol designed for Transmission Control
Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP
speakers within a single autonomous system (AS) must be fully meshed.
This represents a serious scaling problem that has been well documented
in a number of proposals. This document describes an extension to BGP
which may be used to create a confederation of autonomous systems that
is represented as a single autonomous system to BGP peers external to
the confederation, thereby removing the {"}full mesh{"} requirement. The
intention of this extension is to aid in policy administration and
reduce the management complexity of maintaining a large autonomous
system.},
URL="http://www.rfc-editor.org/rfc/rfc3065.txt"
}

@TECHREPORT{rfc3066,
AUTHOR="H. Alvestrand",
TITLE="Tags for the Identification of Languages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3066,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=2001,
ABSTRACT="This document describes a language tag for use in cases where
it is desired to indicate the language used in an information object,
how to register values for use in this language tag, and a construct for
matching such language tags.",
URL="http://www.rfc-editor.org/rfc/rfc3066.txt"
}

@TECHREPORT{rfc3067,
AUTHOR="J. Arvidsson and A. Cormack and Y. Demchenko and J. Meijer",
TITLE="{TERENA'S} Incident Object Description and Exchange Format Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3067,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="The purpose of the Incident Object Description and Exchange
Format is to define a common data format for the description, archiving
and exchange of information about incidents between CSIRTs (Computer
Security Incident Response Teams) (including alert, incident in
investigation, archiving, statistics, reporting, etc.). This document
describes the high-level requirements for such a description and
exchange format, including the reasons for those requirements. Examples
are used to illustrate the requirements where necessary.",
URL="http://www.rfc-editor.org/rfc/rfc3067.txt"
}

@TECHREPORT{rfc3068,
AUTHOR="C. Huitema",
TITLE="An Anycast Prefix for 6to4 Relay Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3068,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT={This memo introduces a {"}6to4 anycast address{"} in order to
simplify the configuration of 6to4 routers. It also defines how this
address will be used by 6to4 relay routers, how the corresponding {"}6to4
anycast prefix{"} will be advertised in the IGP and in the EGP. The memo
documents the reservation by IANA (Internet Assigned Numbers Authority)
of the {"}6to4 relay anycast prefix.{"} This document is a product of the
Next Generation Transistion Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3068.txt"
}

@TECHREPORT{rfc3069,
AUTHOR="D. McPherson and B. Dykes",
TITLE="{VLAN} Aggregation for Efficient {IP} Address Allocation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3069,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This document introduces the concept of Virtual Local Area
Network (VLAN) aggregation as it relates to IPv4 address allocation. A
mechanism is described by which hosts that reside in the same physical
switched infrastructure, but separate virtual broadcast domains, are
addressed from the same IPv4 subnet and share a common default gateway
IP address, thereby removing the requirement of a dedicated IP subnet
for each virtual Local Area Network (LAN) or Metropolitan Area Network
(MAN). Employing such a mechanism significantly decreases IPv4 address
consumption in virtual LANs and MANs. It may also ease administration of
IPv4 addresses within the network.",
URL="http://www.rfc-editor.org/rfc/rfc3069.txt"
}

@TECHREPORT{rfc3070,
AUTHOR="V. Rawat and R. Tio and S. Nanji and R. Verma",
TITLE="Layer Two Tunneling Protocol {(L2TP)} over Frame Relay",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3070,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="Layer Two Tunneling Protocol (L2TP) describes a mechanism to
tunnel Point-to-Point (PPP) sessions. The protocol has been designed to
be independent of the media it runs over. The base specification
describes how it should be implemented to run over the User Datagram
Protocol (UDP) and the Internet Protocol (IP). This document describes
how L2TP is implemented over Frame Relay Permanent Virtual Circuits
(PVCs) and Switched Virtual Circuits (SVCs). This document is a product
of the Layer Two Tunneling Protocol Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3070.txt"
}

@TECHREPORT{rfc3071,
AUTHOR="J. Klensin",
TITLE="Reflections on the {DNS,} {RFC} {1591,} and Categories of Domains",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3071,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT={RFC 1591, {"}Domain Name System Structure and Delegation{"}, laid
out the basic administrative design and principles for the allocation
and administration of domains, from the top level down. It was written
before the introduction of the world wide web (WWW) and rapid growth of
the Internet put significant market, social, and political pressure on
domain name allocations. In recent years, 1591 has been cited by all
sides in various debates, and attempts have been made by various bodies
to update it or adjust its provisions, sometimes under pressures that
have arguably produced policies that are less well thought out than the
original. Some of those efforts have begun from misconceptions about the
provisions of 1591 or the motivation for those provisions. The current
directions of the Internet Corporation for Assigned Names and Numbers
(ICANN) and other groups who now determine the Domain Name System (DNS)
policy directions appear to be drifting away from the policies and
philosophy of 1591. This document is being published primarily for
historical context and comparative purposes, essentially to document
some thoughts about how 1591 might have been interpreted and adjusted by
the Internet Assigned Numbers Authority (IANA) and ICANN to better
reflect today's world while retaining characteristics and policies that
have proven to be effective in supporting Internet growth and stability.
An earlier variation of this memo was submitted to ICANN as a comment on
its evolving Top-level Domain (TLD) policies.},
URL="http://www.rfc-editor.org/rfc/rfc3071.txt"
}

@TECHREPORT{rfc3072,
AUTHOR="M. Wildgrube",
TITLE="Structured Data Exchange Format {(SDXF)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3072,
PAGES=26,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="This specification describes an all-purpose interchange format
for use as a file format or for net-working. Data is organized in chunks
which can be ordered in hierarchical structures. This format is
self-describing and CPU-independent.",
URL="http://www.rfc-editor.org/rfc/rfc3072.txt"
}

@TECHREPORT{rfc3073,
AUTHOR="J. Collins",
TITLE="Portable Font Resource {(PFR)} - application/font-tdpfr {MIME} Sub-type
Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3073,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="This document describes the registration of the Multipurpose
Internet Mail Extensions (MIME) sub-type application/font-tdpfr. The
encoding is defined by the PFR Specification. A Portable Font Resource
(PFR) contains a set of glyph shapes. Each glyph shape is associated
with a character code. The PFR format is designed to be both compact and
platform-independent. It is intended to facilitate accurate rendering of
fonts in all environments whether or not they have the required fonts
already installed.",
URL="http://www.rfc-editor.org/rfc/rfc3073.txt"
}

@TECHREPORT{rfc3074,
AUTHOR="B. Volz and S. Gonczi and T. Lemon and R. Stevens",
TITLE="{DHC} Load Balancing Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3074,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=2001,
ABSTRACT="This document proposes a method of algorithmic load balancing.
It enables multiple, cooperating servers to decide which one should
service a client, without exchanging any information beyond initial
configuration. The server selection is based on the servers hashing
client Media Access Control (MAC) addresses when multiple Dynamic Host
Configuration Protocol (DHCP) servers are available to service DHCP
clients. The proposed technique provides for efficient server selection
when multiple DHCP servers offer services on a network without requiring
any changes to existing DHCP clients. The same method is proposed to
select the target server of a forwarding agent such as a Bootstrap
Protocol (BOOTP) relay. This document is a product of the Dynamic Host
Configuration Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3074.txt"
}

@TECHREPORT{rfc3075,
AUTHOR="D. Eastlake 3rd and J. Reagle and D. Solo",
TITLE="{XML-Signature} Syntax and Processing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3075,
PAGES=64,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="This document specifies XML (Extensible Markup Language)
digital signature processing rules and syntax. XML Signatures provide
integrity, message authentication, and/or signer authentication services
for data of any type, whether located within the XML that includes the
signature or elsewhere. This document is a product of the XML Digital
Signatures Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3075.txt"
}

@TECHREPORT{rfc3076,
AUTHOR="J. Boyer",
TITLE="Canonical {XML} Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3076,
PAGES=28,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="Any XML (Extensible Markup Language) document is part of a set
of XML documents that are logically equivalent within an application
context, but which vary in physical representation based on syntactic
changes permitted by XML 1.0 and Namespaces in XML. This specification
describes a method for generating a physical representation, the
canonical form, of an XML document that accounts for the permissible
changes. Except for limitations regarding a few unusual cases, if two
documents have the same canonical form, then the two documents are
logically equivalent within the given application context. Note that two
documents may have differing canonical forms yet still be equivalent in
a given context based on application-specific equivalence rules for
which no generalized XML specification could account. This document is a
product of the XML Digital Signatures Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3076.txt"
}

@TECHREPORT{rfc3077,
AUTHOR="E. Duros and W. Dabbous and H. Izumiyama and N. Fujii and Y. Zhang",
TITLE="A {Link-Layer} Tunneling Mechanism for Unidirectional Links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3077,
PAGES=25,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT={This document describes a mechanism to emulate full
bidirectional connectivity between all nodes that are directly connected
by a unidirectional link. The {"}receiver{"} uses a link-layer tunneling
mechanism to forward datagrams to {"}feeds{"} over a separate bidirectional
IP (Internet Protocol) network. As it is implemented at the link-layer,
protocols in addition to IP may also be supported by this mechanism.},
URL="http://www.rfc-editor.org/rfc/rfc3077.txt"
}

@TECHREPORT{rfc3078,
AUTHOR="G. Pall and G. Zorn",
TITLE="Microsoft {Point-To-Point} Encryption {(MPPE)} Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3078,
PAGES=12,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links. This document
describes the use of the Microsoft Point to Point Encryption (MPPE) to
enhance the confidentiality of PPP-encapsulated packets. This document
is a product of the Point-to-Point Protocol Extensions Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3078.txt"
}

@TECHREPORT{rfc3079,
AUTHOR="G. Zorn",
TITLE="Deriving Keys for use with Microsoft {Point-to-Point} Encryption {(MPPE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3079,
PAGES=21,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method
for transporting multi-protocol datagrams over point-to-point links. The
PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links. Microsoft
Point to Point Encryption (MPPE) is a means of representing PPP packets
in an encrypted form. MPPE uses the RSA RC4 algorithm to provide data
confidentiality. The length of the session key to be used for
initializing encryption tables can be negotiated. MPPE currently
supports 40-bit, 56-bit and 128-bit session keys. MPPE session keys are
changed frequently; the exact frequency depends upon the options
negotiated, but may be every packet. MPPE is negotiated within option 18
in the Compression Control Protocol. This document describes the method
used to derive initial MPPE session keys from a variety of credential
types. It is expected that this memo will be updated whenever Microsoft
defines a new key derivation method for MPPE, since its primary purpose
is to provide an open, easily accessible reference for third-parties
wishing to interoperate with Microsoft products. MPPE itself (including
the protocol used to negotiate its use, the details of the encryption
method used and the algorithm used to change session keys during a
session) is described in RFC 3078.",
URL="http://www.rfc-editor.org/rfc/rfc3079.txt"
}

@TECHREPORT{rfc3080,
AUTHOR="M. P. Rose",
TITLE="The Blocks Extensible Exchange Protocol Core",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3080,
PAGES=58,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="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. This
document is a product of the Blocks Extensible Exchange Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3080.txt"
}

@TECHREPORT{rfc3081,
AUTHOR="M. P. Rose",
TITLE="Mapping the {BEEP} Core onto {TCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3081,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="This memo describes how a BEEP (Blocks Extensible Exchange
Protocol) session is mapped onto a single TCP (Transmission Control
Protocol) connection. This document is a product of the Blocks
Extensible Exchange Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3081.txt"
}

@TECHREPORT{rfc3082,
AUTHOR="J. Kempf and J. Goldschmidt",
TITLE="Notification and Subscription for {SLP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3082,
PAGES=14,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="The Service Location Protocol (SLP) provides mechanisms
whereby service agent clients can advertise and user agent clients can
query for services. The design is very much demand-driven, so that user
agents only obtain service information when they specifically ask for
it. There exists another class of user agent applications, however, that
requires notification when a new service appears or disappears. In the
RFC 2608 design, these applications are forced to poll the network to
catch changes. In this document, we describe a protocol for allowing
such clients to be notified when a change occurs, removing the need for
polling.",
URL="http://www.rfc-editor.org/rfc/rfc3082.txt"
}

@TECHREPORT{rfc3083,
AUTHOR="R. Woundy",
TITLE="Baseline Privacy Interface Management Information Base for {DOCSIS}
Compliant Cable Modems and Cable Modem Termination Systems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3083,
PAGES=45,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it defines a basic set of managed objects for
SNMP-based (Simple Network Management Protocol) management of the
Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS
1.0 (Data-Over-Cable Service Interface Specifications) compliant Cable
Modems and Cable Modem Termination Systems. This MIB is defined as an
extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This
memo specifies a MIB module in a manner that is compliant to the SMIv2
(Structure of Management Information Version 2). The set of objects is
consistent with the SNMP framework and existing SNMP standards.
CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable
modems that implement the Baseline Privacy Interface, as a prerequisite
for DOCSIS 1.0 certification.",
URL="http://www.rfc-editor.org/rfc/rfc3083.txt"
}

@TECHREPORT{rfc3084,
AUTHOR="K. Chan and J. Seligson and D. Durham and S. Gai and K. McCloghrie and S.
Herzog and F. Reichmeyer and R. Yavatkar",
TITLE="{COPS} Usage for Policy Provisioning {(COPS-PR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3084,
PAGES=34,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="This document describes the use of the Common Open Policy
Service (COPS) protocol for support of policy provisioning (COPS-PR).
This specification is independent of the type of policy being
provisioned (QoS, Security, etc.) but focuses on the mechanisms and
conventions used to communicate provisioned information between PDPs and
PEPs. The protocol extensions described in this document do not make any
assumptions about the policy data model being communicated, but describe
the message formats and objects that carry the modeled policy data. This
document is a product of the Resource Allocation Protocol Working Group
of IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3084.txt"
}

@TECHREPORT{rfc3085,
AUTHOR="A. Coates and D. Allen and D. Rivers-Moore",
TITLE="{URN} Namespace for {NewsML} Resources",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3085,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT="This document describes a URN (Uniform Resource Name)
namespace for identifying NewsML NewsItems. A NewsItem is an information
resource that is expressible as a NewsML element within a NewsML
document conforming to the NewsML Document Type Declaration (DTD) as
defined by the International Press Telecommunications Council (IPTC).",
URL="http://www.rfc-editor.org/rfc/rfc3085.txt"
}

@TECHREPORT{rfc3086,
AUTHOR="K. Nichols and B. E. Carpenter",
TITLE="Definition of Differentiated Services Per Domain Behaviors and Rules for
their Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3086,
PAGES=24,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT={The differentiated services framework enables
quality-of-service provisioning within a network domain by applying
rules at the edges to create traffic aggregates and coupling each of
these with a specific forwarding path treatment in the domain through
use of a codepoint in the IP header. The diffserv WG has defined the
general architecture for differentiated services and has focused on the
forwarding path behavior required in routers, known as {"}per-hop
forwarding behaviors{"} (or PHBs). The WG has also discussed functionality
required at diffserv (DS) domain edges to select (classifiers) and
condition (e.g., policing and shaping) traffic according to the rules.
Short-term changes in the QoS goals for a DS domain are implemented by
changing only the configuration of these edge behaviors without
necessarily reconfiguring the behavior of interior network nodes. The
next step is to formulate examples of how forwarding path components
(PHBs, classifiers, and traffic conditioners) can be used to compose
traffic aggregates whose packets experience specific forwarding
characteristics as they transit a differentiated services domain. The WG
has decided to use the term per-domain behavior, or PDB, to describe the
behavior experienced by a particular set of packets as they cross a DS
domain. A PDB is characterized by specific metrics that quantify the
treatment a set of packets with a particular DSCP (or set of DSCPs) will
receive as it crosses a DS domain. A PDB specifies a forwarding path
treatment for a traffic aggregate and, due to the role that particular
choices of edge and PHB configuration play in its resulting attributes,
it is where the forwarding path and the control plane interact. The
measurable parameters of a PDB should be suitable for use in Service
Level Specifications at the network edge. This document defines and
discusses Per-Domain Behaviors in detail and lays out the format and
required content for contributions to the Diffserv WG on PDBs and the
procedure that will be applied for individual PDB specifications to
advance as WG products. This format is specified to expedite working
group review of PDB submissions. This document is a product of the
Differentiated Services Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3086.txt"
}

@TECHREPORT{rfc3087,
AUTHOR="B. Campbell and R. Sparks",
TITLE="Control of Service Context using {SIP} {Request-URI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3087,
PAGES=39,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="This memo provides information for the Internet community. It
describes a useful way to conceptualize the use of the standard SIP
(Session Initiation Protocol) Request-URI (Uniform Resource Identifier)
that the authors and many members of the SIP community think is suitable
as a convention. It does not define any new protocol with respect to RFC
2543. In a conventional telephony environment, extended service
applications often use call state information, such as calling party,
called party, reason for forward, etc, to infer application context. In
a SIP/2.0 call, much of this information may be either non-existent or
unreliable. This document proposes a mechanism to communicate context
information to an application. Under this proposal, a client or proxy
can communicate context through the use of a distinctive Request-URI.
This document continues with examples of how this mechanism could be
used in a voice mail application.",
URL="http://www.rfc-editor.org/rfc/rfc3087.txt"
}

@TECHREPORT{rfc3088,
AUTHOR="K. Zeilenga",
TITLE="{OpenLDAP} Root Service An experimental {LDAP} referral service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3088,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT={The OpenLDAP Project is operating an experimental LDAP
(Lightweight Directory Access Protocol) referral service known as the
{"}OpenLDAP Root Service{"}. The automated system generates referrals based
upon service location information published in DNS SRV RRs (Domain Name
System location of services resource records). This document describes
this service.},
URL="http://www.rfc-editor.org/rfc/rfc3088.txt"
}

@TECHREPORT{rfc3089,
AUTHOR="H. Kitamura",
TITLE="A {SOCKS-based} {IPv6/IPv4} Gateway Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3089,
PAGES=12,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT={This document describes a SOCKS-based IPv6/IPv4 gateway
mechanism that enables smooth heterogeneous communications between the
IPv6 nodes and IPv4 nodes. It is based on the SOCKS protocol. By
applying the SOCKS mechanism to the heterogeneous communications and
relaying two {"}terminated{"} IPv4 and IPv6 connections at the
{"}application
layer{"} (the SOCKS server), the SOCKS-based IPv6/IPv4 gateway mechanism
is accomplished. Since it is accomplished without introducing new
protocols, it provides the same communication environment that is
provided by the SOCKS mechanism. The same appearance is provided to the
heterogeneous communications. No conveniences or functionalities of
current communications are sacrificed. This document is a product of the
Next Generation Transition Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3089.txt"
}

@TECHREPORT{rfc3090,
AUTHOR="E. Lewis",
TITLE="{DNS} Security Extension Clarification on Zone Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3090,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=2001,
ABSTRACT={The definition of a secured zone is presented, clarifying and
updating sections of RFC 2535. RFC 2535 defines a zone to be secured
based on a per algorithm basis, e.g., a zone can be secured with RSA
keys, and not secured with DSA keys. This document changes this to
define a zone to be secured or not secured regardless of the key
algorithm used (or not used). To further simplify the determination of a
zone's status, {"}experimentally secure{"} status is deprecated. This
document is a product of the DNS Extensions Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3090.txt"
}

@TECHREPORT{rfc3091,
AUTHOR="H. Kennedy",
TITLE="Pi Digit Generation Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3091,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="This memo defines a protocol to provide the Pi digit
generation service (PIgen) used between clients and servers on host
computers.",
URL="http://www.rfc-editor.org/rfc/rfc3091.txt"
}

@TECHREPORT{rfc3092,
AUTHOR="D. Eastlake 3rd and C. Manros and E. Raymond",
TITLE={Etymology of {"}Foo{"}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3092,
PAGES=14,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="Approximately 212 RFCs so far, starting with RFC 269, contain
the terms `foo', `bar', or `foobar' as metasyntactic variables without
any proper explanation or definition. This document rectifies that
deficiency.",
URL="http://www.rfc-editor.org/rfc/rfc3092.txt"
}

@TECHREPORT{rfc3093,
AUTHOR="M. Gaynor and S. Bradner",
TITLE="Firewall Enhancement Protocol {(FEP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3093,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="Internet Transparency via the end-to-end architecture of the
Internet has allowed vast innovation of new technologies and services
[1]. However, recent developments in Firewall technology have altered
this model and have been shown to inhibit innovation. We propose the
Firewall Enhancement Protocol (FEP) to allow innovation, without
violating the security model of a Firewall. With no cooperation from a
firewall operator, the FEP allows ANY application to traverse a
Firewall. Our methodology is to layer any application layer Transmission
Control Protocol/User Datagram Protocol (TCP/UDP) packets over the
HyperText Transfer Protocol (HTTP) protocol, since HTTP packets are
typically able to transit Firewalls. This scheme does not violate the
actual security usefulness of a Firewall, since Firewalls are designed
to thwart attacks from the outside and to ignore threats from within.
The use of FEP is compatible with the current Firewall security model
because it requires cooperation from a host inside the Firewall. FEP
allows the best of both worlds: the security of a firewall, and
transparent tunneling thought the firewall.",
URL="http://www.rfc-editor.org/rfc/rfc3093.txt"
}

@TECHREPORT{rfc3094,
AUTHOR="D. Sprague and R. Benedyk and D. Brendes and J. Keller",
TITLE="Tekelec's Transport Adapter Layer Interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3094,
PAGES=106,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="This document proposes the interfaces of a Signaling Gateway,
which provides interworking between the Switched Circuit Network (SCN)
and an IP network. Since the Gateway is the central point of signaling
information, not only does it provide transportation of signaling from
one network to another, but it can also provide additional functions
such as protocol translation, security screening, routing information,
and seamless access to Intelligent Network (IN) services on both
networks. The Transport Adapter Layer Interface (TALI) is the proposed
interface, which provides TCAP (Transaction Capability Application
Part), ISUP (ISDN User Part), and MTP (Mail Transport Protocol)
messaging over TCP/IP. In addition, TALI provides SCCP (Signalling
Connection Control Part) Management (SCMG), MTP Primitives, dynamic
registration of circuits, and routing of call control messages based on
circuit location.",
URL="http://www.rfc-editor.org/rfc/rfc3094.txt"
}

@TECHREPORT{rfc3095,
AUTHOR="C. Bormann and C. Burmeister and M. Degermark and H. Fukushima and H. Hannu
and L-e. Jonsson and R. Hakenberg and T. Koren",
TITLE="{RObust} Header Compression {(ROHC):} Framework and four profiles: {RTP,}
{UDP,} {ESP,} and uncompressed",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3095,
PAGES=168,
DAYS=15,
MONTH=jul,
YEAR=2001,
ABSTRACT="This document specifies a highly robust and efficient header
compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User
Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating
Security Payload) headers.",
URL="http://www.rfc-editor.org/rfc/rfc3095.txt"
}

@TECHREPORT{rfc3096,
EDITOR="M. Degermark",
TITLE="Requirements for robust {IP/UDP/RTP} header compression",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3096,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=2001,
ABSTRACT={This document contains requirements for robust IP/UDP/RTP
(Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol)
header compression to be developed by the ROHC (Robust Header
Compression) WG. It is based on the ROHC charter, discussions in the WG,
the 3GPP document {"}3GPP TR 23.922{"}, version 1.0.0 of October 1999, as
well as contributions from 3G.IP. This document is a product of the
Robust Header Compression Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3096.txt"
}

@TECHREPORT{rfc3097,
AUTHOR="R. Braden and L. Zhang",
TITLE="{RSVP} Cryptographic Authentication {--} Updated Message Type Value",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3097,
PAGES=4,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="This memo resolves a duplication in the assignment of RSVP
Message Types, by changing the Message Types assigned by RFC 2747 to
Challenge and Integrity Response messages. This document is a product of
the Resource Reservation Setup Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3097.txt"
}

@TECHREPORT{rfc3098,
AUTHOR="T. Gavin and D. Eastlake 3rd and S. Hambridge",
TITLE="How to Advertise Responsibly Using {E-Mail} and Newsgroups or - how {NOT}
to {$$$$$} {MAKE} {ENEMIES} {FAST!} {$$$$$}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3098,
PAGES=28,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="This memo offers useful suggestions for responsible
advertising techniques that can be used via the internet in an
environment where the advertiser, recipients, and the Internet Community
can coexist in a productive and mutually respectful fashion. Some
measure of clarity will also be added to the definitions, dangers, and
details inherent to Internet Marketing.",
URL="http://www.rfc-editor.org/rfc/rfc3098.txt"
}

@TECHREPORT{rfc3099,
AUTHOR="S. Ginoza",
TITLE="Request for Comments Summary {RFC} Numbers {3000-3099}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3099,
PAGES=25,
DAYS=15,
MONTH=nov,
YEAR=2001,
ABSTRACT="This RFC is a slightly annotated list of the 100 RFCs from RFC
3000 through RFCs 3099. This is a status report on these RFCs.",
URL="http://www.rfc-editor.org/rfc/rfc3099.txt"
}

@TECHREPORT{rfc3102,
AUTHOR="M. Borella and J. Lo and D. Grabelsky and Gabriel E. Montenegro",
TITLE="Realm Specific {IP:} Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3102,
PAGES=30,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document examines the general framework of Realm Specific
IP (RSIP). RSIP is intended as a alternative to NAT in which the
end-to-end integrity of packets is maintained. We focus on
implementation issues, deployment scenarios, and interaction with other
layer-three protocols. This document is a product of the Network Address
Translator Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3102.txt"
}

@TECHREPORT{rfc3103,
AUTHOR="M. Borella and D. Grabelsky and J. Lo and K. Taniguchi",
TITLE="Realm Specific {IP:} Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3103,
PAGES=54,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document presents a protocol with which to implement
Realm Specific IP (RSIP). The protocol defined herein allows negotiation
of resources between an RSIP host and gateway, so that the host can
lease some of the gateway's addressing parameters in order to establish
a global network presence. This protocol is designed to operate on the
application layer and to use its own TCP or UDP port. In particular, the
protocol allows a gateway to allocate addressing and control parameters
to a host such that a flow policy can be enforced at the gateway. This
document is a product of the Network Address Translator Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3103.txt"
}

@TECHREPORT{rfc3104,
AUTHOR="Gabriel E. Montenegro and M. Borella",
TITLE="{RSIP} Support for End-to-end {IPsec}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3104,
PAGES=19,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document proposes mechanisms that enable Realm Specific
IP (RSIP) to handle end-to-end IPsec (IP Security). This document is a
product of the Network Address Translator Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3104.txt"
}

@TECHREPORT{rfc3105,
AUTHOR="J. Kempf and Gabriel E. Montenegro",
TITLE="Finding an {RSIP} Server with {SLP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3105,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document contains an SLP service type template that
describes the advertisements made by RSIP servers for their services.
Service Location Protocol (SLP) is an IETF standards track protocol
specifically designed to allow clients to find servers offering
particular services. Since RSIP (Realm Specific IP) clients require a
mechanism to discover RSIP servers, SLP is a natural match for a
solution. The service type template is the basis for an Internet
Assigned Numbers Authority (IANA) standard definition of the
advertisements offered by RSIP servers, an important step toward
interoperability. This document is a product of the Network Address
Translator Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3105.txt"
}

@TECHREPORT{rfc3106,
AUTHOR="D. Eastlake 3rd and T. Goldstein",
TITLE="{ECML} v1.1: Field Specifications for {E-Commerce}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3106,
PAGES=20,
DAYS=15,
MONTH=apr,
YEAR=2001,
ABSTRACT="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. In addition, some fields are defined for merchant to
consumer communication.",
URL="http://www.rfc-editor.org/rfc/rfc3106.txt"
}

@TECHREPORT{rfc3107,
AUTHOR="Y. Rekhter and E. C. Rosen",
TITLE="Carrying Label Information in {BGP-4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3107,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=2001,
ABSTRACT="This document specifies the way in which the label mapping
information for a particular route is piggybacked in the same Border
Gateway Protocol (BGP) Update message that is used to distribute the
route itself. When BGP is used to distribute a particular route, it can
be also be used to distribute a Multiprotocol Label Switching (MPLS)
label which is mapped to that route. This document is a product of the
Multiprotocol Label Switching Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3107.txt"
}

@TECHREPORT{rfc3108,
AUTHOR="R. Krishna Kumar and M. Mostafa",
TITLE="Conventions for the use of the Session Description Protocol {(SDP)} for
{ATM} Bearer Connections",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3108,
PAGES=110,
DAYS=15,
MONTH=may,
YEAR=2001,
ABSTRACT="This document describes conventions for using the Session
Description Protocol (SDP) described in RFC 2327 for controlling ATM
Bearer Connections, and any associated ATM Adaptation Layer (AAL). The
AALs addressed are Type 1, Type 2 and Type 5. This list of conventions
is meant to be exhaustive. Individual applications can use subsets of
these conventions. Further, these conventions are meant to comply
strictly with the SDP syntax as defined in RFC 2327. This document is a
product of the Multiparty Multimedia Session Control Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3108.txt"
}

@TECHREPORT{rfc3109,
AUTHOR="R. Braden and R. Bush and J. Klensin",
TITLE="Request to Move {STD} 39 to Historic Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3109,
PAGES=4,
DAYS=15,
MONTH=may,
YEAR=2001,
ABSTRACT={This memo changes the status of STD 39, BBN Report 1822,
{"}Specification of the Interconnection of a Host and an IMP{"}, from
Standard to Historic.},
URL="http://www.rfc-editor.org/rfc/rfc3109.txt"
}

@TECHREPORT{rfc3110,
AUTHOR="D. Eastlake 3rd",
TITLE="{RSA/SHA-1} {SIGs} and {RSA} {KEYs} in the Domain Name System {(DNS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3110,
PAGES=7,
DAYS=15,
MONTH=may,
YEAR=2001,
ABSTRACT="This document describes how to produce RSA/SHA1 SIG resource
records (RRs) in Section 3 and, so as to completely replace RFC 2537,
describes how to produce RSA KEY RRs in Section 2. Since the adoption of
a Proposed Standard for RSA signatures in the DNS (Domain Name Space),
advances in hashing have been made. A new DNS signature algorithm is
defined to make these advances available in SIG RRs. The use of the
previously specified weaker mechanism is deprecated. The algorithm
number of the RSA KEY RR is changed to correspond to this new SIG
algorithm. No other changes are made to DNS security. This document is a
product of the DNS Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3110.txt"
}

@TECHREPORT{rfc3111,
AUTHOR="E. Guttman",
TITLE="Service Location Protocol Modifications for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3111,
PAGES=13,
DAYS=15,
MONTH=may,
YEAR=2001,
ABSTRACT="This document defines the Service Location Protocol Version
2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP
and TCP, the changes to support its use over IPv6 are minor. This
document does not describe how to use SLPv1 over IPv6 networks. There is
at the time of this publication no implementation or deployment of SLPv1
over IPv6. It is RECOMMENDED that SLPv2 be used in general, and
specifically on networks which support IPv6. This document is a product
of the Service Location Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3111.txt"
}

@TECHREPORT{rfc3112,
AUTHOR="K. Zeilenga",
TITLE="{LDAP} Authentication Password Schema",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3112,
PAGES=9,
DAYS=15,
MONTH=may,
YEAR=2001,
ABSTRACT="This document describes schema in support of user/password
authentication in a LDAP (Lightweight Directory Access Protocol)
directory including the authPassword attribute type. This attribute type
holds values derived from the user's password(s) (commonly using
cryptographic strength one-way hash). authPassword is intended to used
instead of userPassword.",
URL="http://www.rfc-editor.org/rfc/rfc3112.txt"
}

@TECHREPORT{rfc3113,
AUTHOR="K. Rosenbrock and R. Sanmugam and S. Bradner and J. Klensin",
TITLE="{3GPP-IETF} Standardization Collaboration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3113,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document describes the standardization collaboration
between 3GPP and IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3113.txt"
}

@TECHREPORT{rfc3116,
AUTHOR="J. Dunn and C. Dianne Martin",
TITLE="Methodology for {ATM} Benchmarking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3116,
PAGES=127,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document discusses and defines a number of tests that may
be used to describe the performance characteristics of ATM (Asynchronous
Transfer Mode) based switching devices. In addition to defining the
tests this document also describes specific formats for reporting the
results of the tests.",
URL="http://www.rfc-editor.org/rfc/rfc3116.txt"
}

@TECHREPORT{rfc3117,
AUTHOR="M. P. Rose",
TITLE="On the Design of Application Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3117,
PAGES=27,
DAYS=15,
MONTH=nov,
YEAR=2001,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc3117.txt"
}

@TECHREPORT{rfc3118,
EDITOR="R. E. Droms and W. Arbaugh",
TITLE="Authentication for {DHCP} Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3118,
PAGES=17,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document defines a new Dynamic Host Configuration
Protocol (DHCP) option through which authorization tickets can be easily
generated and newly attached hosts with proper authorization can be
automatically configured from an authenticated DHCP server. DHCP
provides a framework for passing configuration information to hosts on a
TCP/IP network. In some situations, network administrators may wish to
constrain the allocation of addresses to authorized hosts. Additionally,
some network administrators may wish to provide for authentication of
the source and contents of DHCP messages. This document is a product of
the Dynamic Host Configuration Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3118.txt"
}

@TECHREPORT{rfc3119,
AUTHOR="R. Finlayson",
TITLE="A More {Loss-Tolerant} {RTP} Payload Format for {MP3} Audio",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3119,
PAGES=19,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT={This document describes a RTP (Real-Time Protocol) payload
format for transporting MPEG (Moving Picture Experts Group) 1 or 2,
layer III audio (commonly known as {"}MP3{"}). This format is an
alternative
to that described in RFC 2250, and performs better if there is packet
loss.},
URL="http://www.rfc-editor.org/rfc/rfc3119.txt"
}

@TECHREPORT{rfc3120,
AUTHOR="K. Best and N. Walsh",
TITLE="A {URN} Namespace for {XML.org}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3120,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document describes a URN (Uniform Resource Name)
namespace that is engineered by the Organization for the Advancement of
Structured Information Standards (OASIS) for naming persistent resources
stored in the XML.org repository (such as XML (Extensible Markup
Language) Document Type Definitions, XML Schemas, Namespaces,
Stylesheets, and other documents).",
URL="http://www.rfc-editor.org/rfc/rfc3120.txt"
}

@TECHREPORT{rfc3121,
AUTHOR="K. Best and N. Walsh",
TITLE="A {URN} Namespace for {OASIS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3121,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document describes a URN (Uniform Resource Name)
namespace that is engineered by the Organization for the Advancement of
Structured Information Standards (OASIS) for naming persistent resources
published by OASIS (such as OASIS Standards, XML (Extensible Markup
Language) Document Type Definitions, XML Schemas, Namespaces,
Stylesheets, and other documents).",
URL="http://www.rfc-editor.org/rfc/rfc3121.txt"
}

@TECHREPORT{rfc3122,
AUTHOR="A. Conta",
TITLE="Extensions to {IPv6} Neighbor Discovery for Inverse Discovery Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3122,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This memo describes extensions to the IPv6 Neighbor Discovery
that allow a node to determine and advertise an IPv6 address
corresponding to a given link-layer address. These extensions are called
Inverse Neighbor Discovery. The Inverse Neighbor Discovery (IND) was
originally developed for Frame Relay networks, but may also apply to
other networks with similar behavior.",
URL="http://www.rfc-editor.org/rfc/rfc3122.txt"
}

@TECHREPORT{rfc3123,
AUTHOR="P. Koch",
TITLE="A {DNS} {RR} Type for Lists of Address Prefixes {(APL} {RR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3123,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT={The Domain Name System (DNS) is primarily used to translate
domain names into IPv4 addresses using A RRs (Resource Records). Several
approaches exist to describe networks or address ranges. This document
specifies a new DNS RR type {"}APL{"} for address prefix lists.},
URL="http://www.rfc-editor.org/rfc/rfc3123.txt"
}

@TECHREPORT{rfc3124,
AUTHOR="H. Balakrishnan and S. Seshan",
TITLE="The Congestion Manager",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3124,
PAGES=22,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document describes the Congestion Manager (CM), an
end-system module that: (i) Enables an ensemble of multiple concurrent
streams from a sender destined to the same receiver and sharing the same
congestion properties to perform proper congestion avoidance and
control, and (ii) Allows applications to easily adapt to network
congestion. This document is a product of the Endpoint Congestion
Management Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3124.txt"
}

@TECHREPORT{rfc3125,
AUTHOR="J. Ross and D. Pinkas and N. Pope",
TITLE="Electronic Signature Policies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3125,
PAGES=44,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document defines signature policies for electronic
signatures. A signature policy is a set of rules for the creation and
validation of an electronic signature, under which the validity of
signature can be determined. A given legal/contractual context may
recognize a particular signature policy as meeting its requirements. A
signature policy has a globally unique reference, which is bound to an
electronic signature by the signer as part of the signature calculation.
The signature policy needs to be available in human readable form so
that it can be assessed to meet the requirements of the legal and
contractual context in which it is being applied. To allow for the
automatic processing of an electronic signature another part of the
signature policy specifies the electronic rules for the creation and
validation of the electronic signature in a computer processable form.
In the current document the format of the signature policy is defined
using ASN.1. The contents of this document is based on the signature
policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org. This document is a product of the S/MIME Mail
Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3125.txt"
}

@TECHREPORT{rfc3126,
AUTHOR="D. Pinkas and J. Ross and N. Pope",
TITLE="Electronic Signature Formats for long term electronic signatures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3126,
PAGES=84,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document defines the format of an electronic signature
that can remain valid over long periods. This includes evidence as to
its validity even if the signer or verifying party later attempts to
deny (i.e., repudiates the validity of the signature). The format can be
considered as an extension to RFC 2630 and RFC 2634, where, when
appropriate additional signed and unsigned attributes have been defined.
The contents of this Informational RFC is technically equivalent to ETSI
TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org This document is a product of the S/MIME Mail
Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3126.txt"
}

@TECHREPORT{rfc3127,
AUTHOR="D. Mitton and M. St. Johns and S. Barkley and D. L. Nelson and B. Patil and
M. L. Stevens and B. Wolff",
TITLE="Authentication, Authorization, and Accounting: Protocol Evaluation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3127,
PAGES=84,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This memo represents the process and findings of the
Authentication, Authorization, and Accounting Working Group (AAA WG)
panel evaluating protocols proposed against the AAA Network Access
Requirements, RFC 2989. Due to time constraints of this report, this
document is not as fully polished as it might have been desired. But it
remains mostly in this state to document the results as presented. This
document is a product of the Authentication, Authorization and
Accounting Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3127.txt"
}

@TECHREPORT{rfc3128,
AUTHOR="I. Miller",
TITLE="Protection Against a Variant of the Tiny Fragment Attack {(RFC} {1858)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3128,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT={This document discusses how RFC 1858 compliant filters can be
vulnerable to a variant of the {"}Tiny Fragment Attack{"} described in
section 3.1 of the RFC. This document describes the attack and
recommends corrective action.},
URL="http://www.rfc-editor.org/rfc/rfc3128.txt"
}

@TECHREPORT{rfc3129,
AUTHOR="M. Thomas",
TITLE="Requirements for Kerberized Internet Negotiation of Keys",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3129,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="The goal of this document is to produce a streamlined, fast,
easily managed, and cryptographically sound protocol without requiring
public key. This document is a product of the Kerberized Internet
Negotiation of Keys Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3129.txt"
}

@TECHREPORT{rfc3130,
AUTHOR="E. Lewis",
TITLE="Notes from the {State-Of-The-Technology:} {DNSSEC}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3130,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This is a memo of a DNSSEC (Domain Name System Security
Extensions) status meeting.",
URL="http://www.rfc-editor.org/rfc/rfc3130.txt"
}

@TECHREPORT{rfc3131,
AUTHOR="S. Bradner and P. Calhoun and H. Cuschieri and S. Dennett and G. Flynn and
M. Lipford and M. J. McPheters",
TITLE="{3GPP2-IETF} Standardization Collaboration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3131,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document describes the standardization collaboration
between 3GPP2 and IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3131.txt"
}

@TECHREPORT{rfc3132,
AUTHOR="J. Kempf",
TITLE={Dormant Mode Host Alerting {({"}IP} Paging{"}) Problem Statement},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3132,
PAGES=14,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This memo describes paging, assesses the need for IP paging,
and presents a list of recommendations for Seamoby charter items
regarding work on paging. The results are specifically directed toward
the task undertaken by the design team, and are not meant to be the
definitive word on paging for all time, nor to be binding on Seamoby or
other working groups, should the situation with regard to IP mobility
protocols or radio link support undergo a major change. This document is
a product of the Context and Micro-mobility Routing Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3132.txt"
}

@TECHREPORT{rfc3133,
AUTHOR="J. Dunn and C. Dianne Martin",
TITLE="Terminology for Frame Relay Benchmarking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3133,
PAGES=24,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This memo discusses and defines terms associated with
performance benchmarking tests and the results of these tests in the
context of frame relay switching devices. THis document is a product of
the Benchmarking Methodology Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3133.txt"
}

@TECHREPORT{rfc3134,
AUTHOR="J. Dunn and C. Dianne Martin",
TITLE="Terminology for {ATM} {ABR} Benchmarking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3134,
PAGES=16,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="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
supporting ABR (Available Bit Rate). The terms defined in this memo will
be used in addition to terms defined in RFCs 1242, 2285, and 2544 and
2761. This memo is a product of the Benchmarking Methodology Working
Group (BMWG) of the Internet Engineering Task Force (IETF). This
document is a product of the Benchmarking Methodology Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3134.txt"
}

@TECHREPORT{rfc3135,
AUTHOR="J. Border and M. Kojo and J. Griner and Gabriel E. Montenegro and Z. Shelby",
TITLE="Performance Enhancing Proxies Intended to Mitigate {Link-Related}
Degradations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3135,
PAGES=45,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document is a survey of Performance Enhancing Proxies
(PEPs) often employed to improve degraded TCP performance caused by
characteristics of specific link environments, for example, in
satellite, wireless WAN, and wireless LAN environments. Different types
of Performance Enhancing Proxies are described as well as the mechanisms
used to improve performance. Emphasis is put on proxies operating with
TCP. In addition, motivations for their development and use are
described along with some of the consequences of using them, especially
in the context of the Internet. This document is a product of the
Performance Implications of Link Characteristics Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3135.txt"
}

@TECHREPORT{rfc3136,
EDITOR="L. Slutsman and I. Faynberg and H. Lu",
TITLE="The {SPIRITS} Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3136,
PAGES=10,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document describes the architecture for supporting
SPIRITS services, which are those originating in the PSTN (Public
Switched Telephone Network)and necessitating the interactions between
the PSTN and the Internet. (Internet Call Waiting, Internet Caller-ID
Delivery, and Internet Call Forwarding are examples of SPIRIT services.)
Specifically, it defines the components constituting the architecture
and the interfaces between the components. This document is a product of
the Service in the PSTN/IN Requesting InTernet Service Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3136.txt"
}

@TECHREPORT{rfc3137,
AUTHOR="A. Retana and L. Nguyen and R. White and A. Zinin and D. McPherson",
TITLE="{OSPF} Stub Router Advertisement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3137,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This memo describes a backward-compatible technique that may
be used by OSPF (Open Shortest Path First) implementations to advertise
unavailability to forward transit traffic or to lower the preference
level for the paths through such a router. In some cases, it is
desirable not to route transit traffic via a specific OSPF router.
However, OSPF does not specify a standard way to accomplish this. This
document is a product of the Open Shortest Path First IGP Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3137.txt"
}

@TECHREPORT{rfc3138,
AUTHOR="D. L. Meyer",
TITLE="Extended Assignments in {233/8}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3138,
PAGES=4,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This memo provides describes the mapping of the GLOP addresses
corresponding to the private AS space. This document is a product of the
MBONE Deployment Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3138.txt"
}

@TECHREPORT{rfc3139,
AUTHOR="L. Sanchez and K. McCloghrie and J. Saperia",
TITLE="Requirements for Configuration Management of {IP-based} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3139,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This memo discusses different approaches to configure networks
and identifies a set of configuration management requirements for
IP-based networks.",
URL="http://www.rfc-editor.org/rfc/rfc3139.txt"
}

@TECHREPORT{rfc3140,
AUTHOR="D. L. Black and S. Brim and B. E. Carpenter and F. Le Faucheur",
TITLE="Per Hop Behavior Identification Codes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3140,
PAGES=8,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document defines a 16 bit encoding mechanism for the
identification of differentiated services Per Hop Behaviors in protocol
messages. It replaces RFC 2836.",
URL="http://www.rfc-editor.org/rfc/rfc3140.txt"
}

@TECHREPORT{rfc3141,
AUTHOR="T. Hiller and P. Walsh and X. Chen and M. Munson and G. Dommety and S.
Sivalingham and B. W. Lim and P. McCann",
TITLE="{CDMA2000} Wireless Data Requirements for {AAA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3141,
PAGES=16,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This memo specifies cdma2000 wireless data AAA
(Authentication, Authorization, Accounting) requirements associated with
third generation wireless architecture that supports roaming among
service providers for traditional PPP and Mobile IP services.",
URL="http://www.rfc-editor.org/rfc/rfc3141.txt"
}

@TECHREPORT{rfc3142,
AUTHOR="J. Hagino and K. Yamamoto",
TITLE="An {IPv6-to-IPv4} Transport Relay Translator",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3142,
PAGES=11,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="The document describes an IPv6-to-IPv4 transport relay
translator (TRT). It enables IPv6-only hosts to exchange {TCP,UDP}
traffic with IPv4-only hosts. A TRT system, which locates in the middle,
translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa. This
document is a product of the Next Generation Transition Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3142.txt"
}

@TECHREPORT{rfc3143,
AUTHOR="I. Cooper and J. Dilley",
TITLE="Known {HTTP} {Proxy/Caching} Problems",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3143,
PAGES=32,
DAYS=15,
MONTH=jun,
YEAR=2001,
ABSTRACT="This document catalogs a number of known problems with World
Wide Web (WWW) (caching) proxies and cache servers. The goal of the
document is to provide a discussion of the problems and proposed
workarounds, and ultimately to improve conditions by illustrating
problems. The construction of this document is a joint effort of the Web
caching community.",
URL="http://www.rfc-editor.org/rfc/rfc3143.txt"
}

@TECHREPORT{rfc3144,
AUTHOR="D. Romascanu",
TITLE="Remote Monitoring {MIB} Extensions for Interface Parameters Monitoring",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3144,
PAGES=30,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. The document proposes an extension to the Remote Monitoring
MIB with a method of sorting the interfaces of a monitored device
according to values of parameters specific to this interface. This
document is a product of the Remote Network Monitoring Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3144.txt"
}

@TECHREPORT{rfc3145,
AUTHOR="R. Verma and M. Verma and J. Carlson",
TITLE="{L2TP} Disconnect Cause Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3145,
PAGES=10,
DAYS=15,
MONTH=jul,
YEAR=2001,
ABSTRACT={This document provides an extension to the Layer 2 Tunneling
Protocol ({"}L2TP{"}), a mechanism for tunneling Point-to-Point Protocol
(PPP) sessions. L2TP lacks a mechanism for a host to provide PPP-related
disconnect cause information to another host. This information, provided
by the extension described in this document, can be useful for
accounting and debugging purposes.},
URL="http://www.rfc-editor.org/rfc/rfc3145.txt"
}

@TECHREPORT{rfc3146,
AUTHOR="K. Fujisawa and A. Onoe",
TITLE="Transmission of {IPv6} Packets over {IEEE} 1394 Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3146,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document describes the frame format for transmission of
IPv6 packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on IEEE1394 networks. This document
is the product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3146.txt"
}

@TECHREPORT{rfc3147,
AUTHOR="P. Christian",
TITLE="Generic Routing Encapsulation over {CLNS} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3147,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=2001,
ABSTRACT="This document proposes a method for transporting an arbitrary
protocol over a CLNS (Connectionless Network Service) network using GRE
(Generic Routing Encapsulation). This may then be used as a method to
tunnel IPv4 or IPv6 over CLNS.",
URL="http://www.rfc-editor.org/rfc/rfc3147.txt"
}

@TECHREPORT{rfc3148,
AUTHOR="M. Mathis and M. Allman",
TITLE="A Framework for Defining Empirical Bulk Transfer Capacity Metrics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3148,
PAGES=16,
DAYS=15,
MONTH=jul,
YEAR=2001,
ABSTRACT="This document defines a framework for standardizing multiple
BTC (Bulk Transport Capacity) metrics that parallel the permitted
transport diversity. This document is a product of the IP Performance
Metrics Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3148.txt"
}

@TECHREPORT{rfc3149,
AUTHOR="A. Srinath and G. Levendel and K. Fritz and R. Kalyanaram",
TITLE="{MGCP} Business Phone Packages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3149,
PAGES=41,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document describes a collection of MGCP (Media Gateway
Control Protocol) packages that can be used to take advantage of the
feature keys and displays on digital business phones and IP-Phones.",
URL="http://www.rfc-editor.org/rfc/rfc3149.txt"
}

@TECHREPORT{rfc3150,
AUTHOR="S. Dawkins and Gabriel E. Montenegro and M. Kojo and V. Magret",
TITLE="End-to-end Performance Implications of Slow Links",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3150,
PAGES=17,
DAYS=15,
MONTH=jul,
YEAR=2001,
ABSTRACT={This document makes performance-related recommendations for
users of network paths that traverse {"}very low bit-rate{"} links. {"}Very
low bit-rate{"} implies {"}slower than we would like{"}. This
recommendation
may be useful in any network where hosts can saturate available
bandwidth, but the design space for this recommendation explicitly
includes connections that traverse 56 Kb/second modem links or 4.8
Kb/second wireless access links - both of which are widely deployed.
This document discusses general-purpose mechanisms. Where
application-specific mechanisms can outperform the relevant
general-purpose mechanism, we point this out and explain why. This
document has some recommendations in common with RFC 2689, {"}Providing
integrated services over low-bitrate links{"}, especially in areas like
header compression. This document focuses more on traditional data
applications for which {"}best-effort delivery{"} is appropriate. This
document is a product of the Performance Implications of Link
Characteristics Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3150.txt"
}

@TECHREPORT{rfc3151,
AUTHOR="N. Walsh and J. Cowan and P. Grosso",
TITLE="A {URN} Namespace for Public Identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3151,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document describes a URN (Uniform Resource Name)
namespace that is designed to allow Public Identifiers to be expressed
in URI (Uniform Resource Identifiers) syntax.",
URL="http://www.rfc-editor.org/rfc/rfc3151.txt"
}

@TECHREPORT{rfc3152,
AUTHOR="R. Bush",
TITLE="Delegation of {IP6.ARPA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3152,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document discusses the need for delegation of the
IP6.ARPA DNS zone, and specifies a plan for the technical operation
thereof.",
URL="http://www.rfc-editor.org/rfc/rfc3152.txt"
}

@TECHREPORT{rfc3153,
AUTHOR="R. Pazhyannur and I. Ali and C. Fox",
TITLE="{PPP} Multiplexing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3153,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document describes a method to reduce the PPP
(Point-to-Point Protocol) framing overhead used to transport small
packets over slow links. This document is a product the Point-to-Point
Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3153.txt"
}

@TECHREPORT{rfc3154,
AUTHOR="J. Kempf and C. Castelluccia and P. Mutaf and N. Nakajima and Y. Ohba and
Ramachandran Ramjee and Y. Saifullah and B. Sarikaya",
TITLE="Requirements and Functional Architecture for an {IP} Host Alerting Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3154,
PAGES=16,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document develops an architecture and a set of
requirements needed to support alerting of hosts that are in dormant
mode. The architecture and requirements are designed to guide
development of an IP protocol for alerting dormant IP mobile hosts,
commonly called paging. This document is a product of the Context
Transfer, Handoff Candidate discovery and Dormant Mode Host Alerting
Working Group of the of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3154.txt"
}

@TECHREPORT{rfc3155,
AUTHOR="S. Dawkins and Gabriel E. Montenegro and M. Kojo and V. Magret and N.
Vaidya",
TITLE="End-to-end Performance Implications of Links with Errors",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3155,
PAGES=16,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document discusses the specific TCP mechanisms that are
problematic in environments with high uncorrected error rates, and
discusses what can be done to mitigate the problems without introducing
intermediate devices into the connection. This document is a product of
the Performance Implications of Link Characteristics Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3155.txt"
}

@TECHREPORT{rfc3156,
AUTHOR="M. Elkins and D. Del Torto and R. Levien and T. Roessler",
TITLE="{MIME} Security with {OpenPGP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3156,
PAGES=15,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document describes how the OpenPGP Message Format can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in RFC
1847. This document is a product of the An Open Specification for Pretty
Good Privacy Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3156.txt"
}

@TECHREPORT{rfc3157,
AUTHOR="A. Arsenault and S. Farrell",
TITLE="Securely Available Credentials - Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3157,
PAGES=20,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document describes requirements to be placed on Securely
Available Credentials (SACRED) protocols. This document is a product of
the Securely Available Credentials Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3157.txt"
}

@TECHREPORT{rfc3158,
AUTHOR="C. E. Perkins and J. Rosenberg and Henning Schulzrinne",
TITLE="{RTP} Testing Strategies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3158,
PAGES=22,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This memo describes a possible testing strategy for RTP
(real-time transport protocol) implementations. This document is a
product of the Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3158.txt"
}

@TECHREPORT{rfc3159,
AUTHOR="K. McCloghrie and M. Fine and J. Seligson and K. Chan and S. Hahn and R.
Sahita and A. J. Smith and F. Reichmeyer",
TITLE="Structure of Policy Provisioning Information {(SPPI)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3159,
PAGES=40,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document, the Structure of Policy Provisioning
Information (SPPI), defines the adapted subset of SNMP's Structure of
Management Information (SMI) used to write Policy Information Base (PIB)
modules. RFC 2748 defines the COPS protocol, and RFC 2749 describes how
the COPS protocol is used to provide for the outsourcing of policy
decisions for RSVP. Another usage of the COPS protocol, for the
provisioning of policy, is introduced in RFC 3084. In this provisioning
model, the policy information is viewed as a collection of Provisioning
Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual
information store, termed the Policy Information Base (PIB). Collections
of related Provisioning Classes are defined in a PIB module. This
document is a product of the Resource Allocation Protocol Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3159.txt"
}

@TECHREPORT{rfc3160,
AUTHOR="S. J. Harris",
TITLE="The Tao of {IETF} - A Novice's Guide to the Internet Engineering Task Force",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3160,
PAGES=38,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document describes the inner workings of IETF meetings
and Working Groups, discusses organizations related to the IETF, and
introduces the standards process.",
URL="http://www.rfc-editor.org/rfc/rfc3160.txt"
}

@TECHREPORT{rfc3161,
AUTHOR="C. J. Adams and P. Cain and D. Pinkas and R. Zuccherato",
TITLE="Internet {X.509} Public Key Infrastructure {Time-Stamp} Protocol {(TSP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3161,
PAGES=26,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document describes the format of a request sent to a Time
Stamping Authority (TSA) and of the response that is returned. It also
establishes several security-relevant requirements for TSA operation,
with regards to processing requests to generate responses. This document
is a product of the Public-Key Infrastructure (C.509) Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3161.txt"
}

@TECHREPORT{rfc3162,
AUTHOR="B. Aboba and G. Zorn and D. Mitton",
TITLE="{RADIUS} and {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3162,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document specifies the operation of RADIUS (Remote
Authentication Dial In User Service) when run over IPv6 as well as the
RADIUS attributes used to support IPv6 network access.",
URL="http://www.rfc-editor.org/rfc/rfc3162.txt"
}

@TECHREPORT{rfc3163,
AUTHOR="R. Zuccherato and M. Nystrom",
TITLE="{ISO/IEC} {9798-3} Authentication {SASL} Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3163,
PAGES=17,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document defines a SASL (Simple Authentication and
Security Layer) authentication mechanism based on ISO/IEC 9798-3 and
FIPS PUB 196 entity authentication.",
URL="http://www.rfc-editor.org/rfc/rfc3163.txt"
}

@TECHREPORT{rfc3164,
AUTHOR="C. Lonvick",
TITLE="The {BSD} Syslog Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3164,
PAGES=29,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This document describes the observed behavior of the syslog
protocol. This protocol has been used for the transmission of event
notification messages across networks for many years. While this
protocol was originally developed on the University of California
Berkeley Software Distribution (BSD) TCP/IP system implementations, its
value to operations and management has led it to be ported to many other
operating systems as well as being embedded into many other networked
devices. This document is a product of the Security Issues in Network
Event Logging Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3164.txt"
}

@TECHREPORT{rfc3165,
AUTHOR="D. Levi and J. Schoenwaelder",
TITLE="Definitions of Managed Objects for the Delegation of Management Scripts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3165,
PAGES=64,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes a set of managed objects that
allow the delegation of management scripts to distributed managers. This
document is a product of the Distributed Management Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3165.txt"
}

@TECHREPORT{rfc3166,
AUTHOR="D. L. Meyer and J. Scudder",
TITLE="Request to Move {RFC} 1403 to Historic Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3166,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT={RFC 1403, {"}BGP OSPF Interaction{"}, describes technology which
is no longer used. This document requests that RFC 1403 be moved to
Historic status.},
URL="http://www.rfc-editor.org/rfc/rfc3166.txt"
}

@TECHREPORT{rfc3167,
AUTHOR="D. L. Meyer and J. Scudder",
TITLE="Request to Move {RFC} 1745 to Historic Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3167,
PAGES=3,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT={RFC 1745, {"}BGP4/IDRP for IP---OSPF Interaction{"}, describes
technology which was never deployed in the public internet. This
document requests that RFC 1745 be moved to Historic status.},
URL="http://www.rfc-editor.org/rfc/rfc3167.txt"
}

@TECHREPORT{rfc3168,
AUTHOR="K. G. Ramakrishnan and S. Floyd and D. L. Black",
TITLE="The Addition of Explicit Congestion Notification {(ECN)} to {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3168,
PAGES=63,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This memo specifies the incorporation of ECN (Explicit
Congestion Notification) to TCP and IP, including ECN's use of two bits
in the IP header. This document is a product of the Transport Area
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3168.txt"
}

@TECHREPORT{rfc3169,
AUTHOR="M. Beadles and D. Mitton",
TITLE="Criteria for Evaluating Network Access Server Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3169,
PAGES=17,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document defines requirements for protocols used by
Network Access Servers (NAS). This document is a product of the Network
Access Server Requirements Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3169.txt"
}

@TECHREPORT{rfc3170,
AUTHOR="B. Quinn and Kevin C Almeroth",
TITLE="{IP} Multicast Applications: Challenges and Solutions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3170,
PAGES=28,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document describes the challenges involved with designing
and implementing multicast applications. It is an introductory guide for
application developers that highlights the unique considerations of
multicast applications as compared to unicast applications. To this end,
the document presents a taxonomy of multicast application I/O models and
examples of the services they can support. It then describes the service
requirements of these multicast applications, and the recent and ongoing
efforts to build protocol solutions to support these services.",
URL="http://www.rfc-editor.org/rfc/rfc3170.txt"
}

@TECHREPORT{rfc3171,
AUTHOR="Z. Albanna and Kevin C Almeroth and D. L. Meyer and M. Schipper",
TITLE="{IANA} Guidelines for {IPv4} Multicast Address Assignments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3171,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=2001,
ABSTRACT="This memo provides guidance for the Internet Assigned Numbers
Authority (IANA) in assigning IPv4 multicast addresses.",
URL="http://www.rfc-editor.org/rfc/rfc3171.txt"
}

@TECHREPORT{rfc3172,
EDITOR="G. Huston",
TITLE={Management Guidelines \& Operational Requirements for the Address and
Routing Parameter Area Domain ({"}arpa{"})},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3172,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT={This memo describes the management and operational
requirements for the address and routing parameter area ({"}arpa{"})
domain.
The {"}arpa{"} domain is used to support a class of infrastructural
identifier spaces, providing a distributed database that translates
elements of a structured name space derived from a protocol family to
service names. The efficient and reliable operation of this DNS space is
essential to the integrity of operation of various services within the
Internet. The Internet Architecture Board (IAB) has the responsibility,
in cooperation with the Internet Corporation for Assigned Names and
Numbers (ICANN), to manage the {"}arpa{"} domain. This document describes
the principles used by the IAB in undertaking this role. This document
is a product of the Internet Architecture Board.},
URL="http://www.rfc-editor.org/rfc/rfc3172.txt"
}

@TECHREPORT{rfc3173,
AUTHOR="A. Shacham and B. Monsour and R. Pereira and M. Thomas",
TITLE="{IP} Payload Compression Protocol {(IPComp)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3173,
PAGES=13,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document describes a protocol intended to provide
lossless compression for Internet Protocol datagrams in an Internet
environment.",
URL="http://www.rfc-editor.org/rfc/rfc3173.txt"
}

@TECHREPORT{rfc3174,
AUTHOR="D. Eastlake 3rd and P. Jones",
TITLE="{US} Secure Hash Algorithm 1 {(SHA1)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3174,
PAGES=22,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT={The purpose of this document is to make the SHA-1 (Secure Hash
Algorithm 1) hash algorithm conveniently available to the Internet
community. The United States of America has adopted the SHA-1 hash
algorithm described herein as a Federal Information Processing Standard.
Most of the text herein was taken by the authors from FIPS 180-1. Only
the C code implementation is {"}original{"}. This document is a product of
the Individual Submissions Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3174.txt"
}

@TECHREPORT{rfc3175,
AUTHOR="F. Baker and C. Iturralde and F. Le Faucheur and B. S. Davie",
TITLE="Aggregation of {RSVP} for {IPv4} and {IPv6} Reservations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3175,
PAGES=36,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document describes the use of a single RSVP (Resource
ReSerVation Protocol) reservation to aggregate other RSVP reservations
across a transit routing region, in a manner conceptually similar to the
use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It
proposes a way to dynamically create the aggregate reservation, classify
the traffic for which the aggregate reservation applies, determine how
much bandwidth is needed to achieve the requirement, and recover the
bandwidth when the sub-reservations are no longer required. It also
contains recommendations concerning algorithms and policies for
predictive reservations.",
URL="http://www.rfc-editor.org/rfc/rfc3175.txt"
}

@TECHREPORT{rfc3176,
AUTHOR="P. Phaal and S. Panchen and N. McKee",
TITLE="{InMon} Corporation's sFlow: A Method for Monitoring Traffic in Switched
and Routed Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3176,
PAGES=31,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This memo defines InMon Corporation's sFlow system. sFlow is a
technology for monitoring traffic in data networks containing switches
and routers. In particular, it defines the sampling mechanisms
implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for
controlling the sFlow Agent, and the format of sample data used by the
sFlow Agent when forwarding data to a central data collector.",
URL="http://www.rfc-editor.org/rfc/rfc3176.txt"
}

@TECHREPORT{rfc3177,
AUTHOR="Anton Riabov and  Iesg",
TITLE="{IAB/IESG} Recommendations on {IPv6} Address",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3177,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document provides recommendations to the addressing
registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6
address blocks to end sites. In particular, it recommends the assignment
of /48 in the general case, /64 when it is known that one and only one
subnet is needed and /128 when it is absolutely known that one and only
one device is connecting. The original recommendations were made in an
IAB/IESG statement mailed to the registries on September 1, 2000. This
document refines the original recommendation and documents it for the
historical record. This document is a product of the Internet
Engineering Steering Group.",
URL="http://www.rfc-editor.org/rfc/rfc3177.txt"
}

@TECHREPORT{rfc3178,
AUTHOR="J. Hagino and H. Snyder",
TITLE="{IPv6} Multihoming Support at Site Exit Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3178,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="The document describes a mechanism for basic IPv6 multihoming
support, and its operational requirements. Unlike currently-practiced
IPv4 multihoming, the technique does not impact the worldwide routing
table size, nor IGP (Interior Gateway Protocol) routing table size in
upstream ISPs. The mechanism can be combined with more sophisticated (or
complex) multihoming support mechanisms, and can be used as a foundation
for other mechanisms. The document is largely based on RFC 2260 by Tony
Bates. This document is a product of the IPNG Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3178.txt"
}

@TECHREPORT{rfc3179,
AUTHOR="J. Schoenwaelder and Juergen Quittek",
TITLE="Script {MIB} Extensibility Protocol Version {1.1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3179,
PAGES=25,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="The Script MIB extensibility protocol (SMX) defined in this
memo separates language specific runtime systems from language
independent Script MIB implementations. 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.",
URL="http://www.rfc-editor.org/rfc/rfc3179.txt"
}

@TECHREPORT{rfc3180,
AUTHOR="D. L. Meyer and P. Lothberg",
TITLE="{GLOP} Addressing in {233/8}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3180,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2001,
ABSTRACT="This document defines the policy for the use of 233/8 for
statically assigned multicast addresses. This document is a product of
the MBONE Deployment Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3180.txt"
}

@TECHREPORT{rfc3181,
AUTHOR="S. Herzog",
TITLE="Signaled Preemption Priority Policy Element",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3181,
PAGES=12,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document describes a preemption priority policy element
for use by signaled policy based admission protocols (such as the
Resource ReSerVation Protocol (RSVP) and Common Open Policy Service
(COPS). 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.
This memo corrects an RSVP POLICY\_DATA P-Type codepoint assignment error
in RFC 2751. This document is a product of the Resource Allocation
Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3181.txt"
}

@TECHREPORT{rfc3182,
AUTHOR="S. Yadav and R. Yavatkar and R. Pabbati and P. Ford and T. E. Moore and S.
Herzog and R. Hess",
TITLE="Identity Representation for {RSVP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3182,
PAGES=18,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document describes the representation of identity
information in POLICY\_DATA object for supporting policy based admission
control in the Resource ReSerVation Protocol (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. This memo corrects an
RSVP POLICY\_DATA P-Type codepoint assignment error and a field size
definition error in ErrorValue in RFC 2752. This document is a product
of the Resource Allocation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3182.txt"
}

@TECHREPORT{rfc3183,
AUTHOR="T. Dean and W. Ottaway",
TITLE="Domain Security Services using {S/MIME}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3183,
PAGES=24,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document describes how the S/MIME (Secure/Multipurpose
Internet Mail Extensions) protocol can be processed and generated by a
number of components of a communication system, such as message transfer
agents, guards and gateways to deliver security services. These services
are collectively referred to as 'Domain Security Services'.",
URL="http://www.rfc-editor.org/rfc/rfc3183.txt"
}

@TECHREPORT{rfc3184,
AUTHOR="S. J. Harris",
TITLE="{IETF} Guidelines for Conduct",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3184,
PAGES=4,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document provides a set of guidelines for personal
interaction in the Internet Engineering Task Force. The Guidelines
recognize the diversity of IETF participants, emphasize the value of
mutual respect, and stress the broad applicability of our work. This
document is a product of the Process for Organization of Internet
Standards ONgoing Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3184.txt"
}

@TECHREPORT{rfc3185,
AUTHOR="S. Farrell and S. J. Turner",
TITLE="Reuse of {CMS} Content Encryption Keys",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3185,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document describes a way to include a key identifier in a
CMS (Cryptographic Message Syntax) enveloped data structure, so that the
content encryption key can be re-used for further enveloped data
packets. This document is a product of the S/MIME Mail Security Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3185.txt"
}

@TECHREPORT{rfc3186,
AUTHOR="S. Shimizu and T. Kawano and K. Murakami and E. Beier",
TITLE="{MAPOS/PPP} Tunneling mode",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3186,
PAGES=14,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document specifies tunneling configuration over MAPOS
(Multiple Access Protocol over SONET/SDH) networks. Using this mode, a
MAPOS network can provide transparent point-to-point link for PPP over
SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead.",
URL="http://www.rfc-editor.org/rfc/rfc3186.txt"
}

@TECHREPORT{rfc3187,
AUTHOR="J. Hakala and H. Walravens",
TITLE="Using International Standard Book Numbers as Uniform Resource Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3187,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document discusses how International Standard Book
Numbers (ISBN) can be supported within the URN (Uniform Resource Names)
framework and the syntax for URNs defined in RFC 2141. Much of the
discussion below is based on the ideas expressed in RFC 2288.",
URL="http://www.rfc-editor.org/rfc/rfc3187.txt"
}

@TECHREPORT{rfc3188,
AUTHOR="J. Hakala",
TITLE="Using National Bibliography Numbers as Uniform Resource Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3188,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This document discusses how national bibliography numbers
(persistent and unique identifiers assigned by the national libraries)
can be supported within the URN (Uniform Resource Names) framework and
the syntax for URNs defined in RFC 2141. Much of the discussion is based
on the ideas expressed in RFC 2288.",
URL="http://www.rfc-editor.org/rfc/rfc3188.txt"
}

@TECHREPORT{rfc3191,
AUTHOR="C. Allocchio",
TITLE="Minimal {GSTN} address format in Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3191,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT={This memo describes a simple method of encoding Global
Switched Telephone Network (GSTN) addresses (commonly called {"}telephone
numbers{"}) 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 GSTN-based services. This document is a
product of the Internet Fax Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3191.txt"
}

@TECHREPORT{rfc3192,
AUTHOR="C. Allocchio",
TITLE="Minimal {FAX} address format in Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3192,
PAGES=11,
DAYS=15,
MONTH=oct,
YEAR=2001,
ABSTRACT="This memo describes a simple method of encoding Global
Switched Telephone Network (GSTN) addresses of facsimile devices in the
local-part of Internet email addresses. This document is a product of
the Internet Fax Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3192.txt"
}

@TECHREPORT{rfc3193,
AUTHOR="B. Patel and B. Aboba and W. J. Dixon and G. Zorn and S. Booth",
TITLE="Securing {L2TP} using {IPsec}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3193,
PAGES=28,
DAYS=15,
MONTH=nov,
YEAR=2001,
ABSTRACT="This document discusses how L2TP (Layer Two Tunneling
Protocol) may utilize IPsec to provide for tunnel authentication,
privacy protection, integrity checking and replay protection. Both the
voluntary and compulsory tunneling cases are discussed. This document is
a product of the Layer Two Tunneling Protocol Extensions Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3193.txt"
}

@TECHREPORT{rfc3194,
AUTHOR="A. Durand and C. Huitema",
TITLE="The {H-Density} Ratio for Address Assignment Efficiency An Update on the H
ratio",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3194,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=2001,
ABSTRACT={This document provides an update on the {"}H ratio{"} defined in
RFC 1715. It defines a new ratio which the authors claim is easier to
understand.},
URL="http://www.rfc-editor.org/rfc/rfc3194.txt"
}

@TECHREPORT{rfc3195,
AUTHOR="D. New and M. P. Rose",
TITLE="Reliable Delivery for syslog",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3195,
PAGES=36,
DAYS=15,
MONTH=nov,
YEAR=2001,
ABSTRACT="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. This document is a product of the Security Issues in Network
Event Logging Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3195.txt"
}

@TECHREPORT{rfc3196,
AUTHOR="T. Hastings and C. Manros and P. Zehler and C. Kugler and H. Holst",
TITLE="Internet Printing Protocol/1.1: Implementor's Guide",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3196,
PAGES=96,
DAYS=15,
MONTH=nov,
YEAR=2001,
ABSTRACT="This document is one of a set of documents, which together
describe all aspects of a new Internet Printing Protocol (IPP). This
document is a product of the Internet Printing Protocol Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3196.txt"
}

@TECHREPORT{rfc3197,
AUTHOR="R. Austein",
TITLE="Applicability Statement for {DNS} {MIB} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3197,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=2001,
ABSTRACT="This document explains why, after more than six years as
proposed standards, the DNS Server and Resolver MIB extensions were
never deployed, and recommends retiring these MIB extensions by moving
them to Historical status.",
URL="http://www.rfc-editor.org/rfc/rfc3197.txt"
}

@TECHREPORT{rfc3198,
AUTHOR="A. Westerinen and J. Schnizlein and J. Strassner and M. Scherling and B.
Quinn and S. Herzog and A. Huynh and M. Carlson",
TITLE="Terminology for {Policy-Based} Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3198,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=2001,
ABSTRACT="This document is a glossary of policy-related terms. It
provides abbreviations, explanations, and recommendations for use of
these terms. The document takes the approach and format of RFC 2828,
which defines an Internet Security Glossary. The intent is to improve
the comprehensibility and consistency of writing that deals with network
policy, particularly Internet Standards documents (ISDs).",
URL="http://www.rfc-editor.org/rfc/rfc3198.txt"
}

@TECHREPORT{rfc3203,
AUTHOR="Y. T'Joens and C. Hublet and P. De Schrijver",
TITLE="{DHCP} reconfigure extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3203,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document defines extensions to DHCP (Dynamic Host
Configuration Protocol) to allow dynamic reconfiguration of a single
host triggered by the DHCP server (e.g., a new IP address and/or local
configuration parameters). This is achieved by introducing a unicast
FORCERENEW message which forces the client to the RENEW state. The
behaviour for hosts using the DHCP INFORM message to obtain
configuration information is also described. This document is a product
of the Dynamic Host Configuration Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3203.txt"
}

@TECHREPORT{rfc3204,
AUTHOR="E. Zimmerer and J. Peterson and A. Vemuri and L. Ong and F. Audet and M.
Watson and M. Zonoun",
TITLE="{MIME} media types for {ISUP} and {QSIG} Objects",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3204,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document describes MIME types for application/ISUP and
application/QSIG objects for use in SIP applications, according to the
rules defined in RFC 2048. These types can be used to identify ISUP and
QSIG objects within a SIP message such as INVITE or INFO, as might be
implemented when using SIP in an environment where part of the call
involves interworking to the PSTN. This document is a product of the
Session Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3204.txt"
}

@TECHREPORT{rfc3208,
AUTHOR="T. Speakman and Jon Crowcroft and J. Gemmell and D. Farinacci and S. Lin
and D. Leshchiner and M. Luby and T. Montgomery",
TITLE="{PGM} Reliable Transport Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3208,
PAGES=111,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="Pragmatic General Multicast (PGM) is a reliable multicast
transport protocol for applications that require ordered or unordered,
duplicate-free, multicast data delivery from multiple sources to
multiple receivers. PGM guarantees that a receiver in the group either
receives all data packets from transmissions and repairs, or is able to
detect unrecoverable data packet loss. PGM is specifically intended as a
workable solution for multicast applications with basic reliability
requirements. Its central design goal is simplicity of operation with
due regard for scalability and network efficiency.",
URL="http://www.rfc-editor.org/rfc/rfc3208.txt"
}

@TECHREPORT{rfc3209,
AUTHOR="Daniel O. Awduche and L. Berger and D. Gan and T. Li and V. Srinivasan and
G. Swallow",
TITLE="{RSVP-TE:} Extensions to {RSVP} for {LSP} Tunnels",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3209,
PAGES=61,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document describes the use of RSVP (Resource Reservation
Protocol), including all the necessary extensions, to establish
label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).
Since the flow along an LSP is completely identified by the label
applied at the ingress node of the path, these paths may be treated as
tunnels. A key application of LSP tunnels is traffic engineering with
MPLS as specified in RFC 2702. We propose several additional objects
that extend RSVP, allowing the establishment of explicitly routed label
switched paths using RSVP as a signaling protocol. The result is the
instantiation of label-switched tunnels which can be automatically
routed away from network failures, congestion, and bottlenecks. This
document is a product of the Multiprotocol Label Switching Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3209.txt"
}

@TECHREPORT{rfc3210,
AUTHOR="Daniel O. Awduche and A. Hannan and X. Xiao",
TITLE="Applicability Statement for Extensions to {RSVP} for {LSP-Tunnels}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3210,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT={This memo discusses the applicability of {"}Extensions to RSVP
(Resource ReSerVation Protocol) for LSP Tunnels{"}. It highlights the
protocol's principles of operation and describes the network context for
which it was designed. Guidelines for deployment are offered and known
protocol limitations are indicated. This document is intended to
accompany the submission of {"}Extensions to RSVP for LSP Tunnels{"} onto
the Internet standards track. This document is a product of the
Multiprotocol Label Switching Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3210.txt"
}

@TECHREPORT{rfc3211,
AUTHOR="P. Gutmann",
TITLE="Password-based Encryption for {CMS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3211,
PAGES=17,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document provides a method of encrypting data using
user-supplied passwords and, by extension, any form of variable-length
keying material which is not necessarily an algorithm-specific
fixed-format key. The Cryptographic Message Syntax data format does not
currently contain any provisions for password-based data encryption.",
URL="http://www.rfc-editor.org/rfc/rfc3211.txt"
}

@TECHREPORT{rfc3216,
AUTHOR="C. Elliott and D. Harrington and J. Jason and J. Schoenwaelder and F.
Strauss and W. Weiss",
TITLE="{SMIng} Objectives",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3216,
PAGES=33,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document describes the objectives for a new data
definition language, suitable for the modeling of network management
constructs, that can be directly mapped into SNMP and COPS-PR protocol
operations. The purpose of this document is to serve as a set of
objectives that a subsequent language specification should try to
address. It captures the results of the working group discussions
towards consensus on the SMIng objectives. This document is a product of
the Next Generation Structure of Management Information Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3216.txt"
}

@TECHREPORT{rfc3217,
AUTHOR="R. Housley",
TITLE="{Triple-DES} and {RC2} Key Wrapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3217,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document specifies the algorithm for wrapping one
Triple-DES key with another Triple-DES key and the algorithm for
wrapping one RC2 key with another RC2 key. These key wrap algorithms
were originally published in section 12.6 of RFC 2630. They are
republished since these key wrap algorithms have been found to be useful
in contexts beyond those supported by RFC 2630. This document is a
product of the S/MIME Mail Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3217.txt"
}

@TECHREPORT{rfc3221,
AUTHOR="G. Huston",
TITLE="Commentary on {Inter-Domain} Routing in the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3221,
PAGES=25,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document examines the various longer term trends visible
within the characteristics of the Internet's BGP table and identifies a
number of operational practices and protocol factors that contribute to
these trends. The potential impacts of these practices and protocol
properties on the scaling properties of the inter-domain routing space
are examined. This document is the outcome of a collaborative exercise
on the part of the Internet Architecture Board.",
URL="http://www.rfc-editor.org/rfc/rfc3221.txt"
}

@TECHREPORT{rfc3222,
AUTHOR="G. Trotter",
TITLE="Terminology for Forwarding Information Base {(FIB)} based Router
Performance",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3222,
PAGES=15,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document describes the terms to be used in a methodology
that determines the IP packet forwarding performance of IP routers as a
function of the forwarding information base installed within a router.
The forwarding performance of an IP router may be dependent upon or may
be linked to the composition and size of the forwarding information base
installed within a router. This document is a product of the
Benchmarking Methodology Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3222.txt"
}

@TECHREPORT{rfc3225,
AUTHOR="D. Conrad",
TITLE="Indicating Resolver Support of {DNSSEC}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3225,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="In order to deploy DNSSEC (Domain Name System Security
Extensions) operationally, DNSSEC aware servers should only perform
automatic inclusion of DNSSEC RRs when there is an explicit indication
that the resolver can understand those RRs. This document proposes the
use of a bit in the EDNS0 header to provide that explicit indication and
describes the necessary protocol changes to implement that notification.
This document is a product of the DNS Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3225.txt"
}

@TECHREPORT{rfc3226,
AUTHOR="O. Gudmundsson",
TITLE="{DNSSEC} and {IPv6} {A6} aware server/resolver message size requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3226,
PAGES=6,
DAYS=15,
MONTH=dec,
YEAR=2001,
ABSTRACT="This document mandates support for EDNS0 (Extension Mechanisms
for DNS) in DNS entities claiming to support either DNS Security
Extensions or A6 records. This requirement is necessary because these
new features increase the size of DNS messages. If EDNS0 is not
supported fall back to TCP will happen, having a detrimental impact on
query latency and DNS server load. This document updates RFC 2535 and
RFC 2874, by adding new requirements. This document is a product of the
DNS Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3226.txt"
}

@TECHREPORT{rfc3114,
AUTHOR="W. Nicolls",
TITLE="Implementing Company Classification Policy with the {S/MIME} Security Label",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3114,
PAGES=14,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This document discusses how company security policy for data
classification can be mapped to the S/MIME security label. Actual
policies from three companies provide worked examples. This document is
a product of the S/MIME Mail Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3114.txt"
}

@TECHREPORT{rfc3189,
AUTHOR="K. Kobayashi and A. Ogawa and S. Casner and C. Bormann",
TITLE="{RTP} Payload Format for {DV} {(IEC} {61834)} Video",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3189,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT={This document specifies the packetization scheme for
encapsulating the compressed digital video data streams commonly known
as {"}DV{"} into a payload format for the Real-Time Transport Protocol
(RTP). This document is a product of the Audio/Video Transport Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3189.txt"
}

@TECHREPORT{rfc3190,
AUTHOR="K. Kobayashi and A. Ogawa and S. Casner and C. Bormann",
TITLE="{RTP} Payload Format for 12-bit {DAT} Audio and {20-} and 24-bit Linear
Sampled Audio",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3190,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document specifies a packetization scheme for
encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio
data streams using the Real-time Transport Protocol (RTP). This document
also specifies the format of a Session Description Protocol (SDP)
parameter to indicate when audio data is preemphasized before sampling.
The parameter may be used with other audio payload formats, in
particular L16 (16-bit linear). This document is a product of the
Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3190.txt"
}

@TECHREPORT{rfc3201,
AUTHOR="R. Steinberger and O. Nicklass",
TITLE="Definitions of Managed Objects for Circuit to Interface Translation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3201,
PAGES=23,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This memo defines an extension 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 insertion
of interesting Circuit Interfaces into the ifTable. This is important
for circuits that must be used within other MIB modules which require an
ifEntry. It allows for integrated monitoring of circuits as well as
routing to circuits using unaltered, pre-existing MIB modules. This
document is a product of the Frame Relay Service MIB Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3201.txt"
}

@TECHREPORT{rfc3202,
AUTHOR="R. Steinberger and O. Nicklass",
TITLE="Definitions of Managed Objects for Frame Relay Service Level Definitions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3202,
PAGES=64,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This memo defines an extension 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 Frame
Relay Service Level Definitions. This document is a product of the Frame
Relay Service MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3202.txt"
}

@TECHREPORT{rfc3205,
AUTHOR="K. Moore",
TITLE="On the use of {HTTP} as a Substrate",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3205,
PAGES=14,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT="Recently there has been widespread interest in using Hypertext
Transfer Protocol (HTTP) as a substrate for other applications-level
protocols. This document recommends technical particulars of such use,
including use of default ports, URL schemes, and HTTP security
mechanisms.",
URL="http://www.rfc-editor.org/rfc/rfc3205.txt"
}

@TECHREPORT{rfc3206,
AUTHOR="R. Gellens",
TITLE="The {SYS} and {AUTH} {POP} Response Codes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3206,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT="This memo proposes two response codes: SYS and AUTH, which
enable clients to unambiguously determine an optimal response to an
authentication failure. In addition, a new capability (AUTH-RESP-CODE)
is defined.",
URL="http://www.rfc-editor.org/rfc/rfc3206.txt"
}

@TECHREPORT{rfc3207,
AUTHOR="P. Hoffman",
TITLE="{SMTP} Service Extension for Secure {SMTP} over Transport Layer Security",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3207,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT="This document describes an extension to the SMTP (Simple Mail
Transfer Protocol) service that allows an SMTP server and client to use
TLS (Transport Layer Security) to provide private, authenticated
communication over the Internet. This gives SMTP agents the ability to
protect some or all of their communications from eavesdroppers and
attackers.",
URL="http://www.rfc-editor.org/rfc/rfc3207.txt"
}

@TECHREPORT{rfc3212,
EDITOR="B. Jamoussi and L. Andersson and R. Callon",
TITLE="{Constraint-Based} {LSP} Setup using {LDP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3212,
PAGES=42,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document specifies mechanisms and TLVs
(Type/Length/Value) for support of CR-LSPs (constraint-based routed
Label Switched Path) using LDP (Label Distribution Protocol). This
specification proposes an end-to-end setup mechanism of a CR-LSP
initiated by the ingress LSR (Label Switching Router). We also specify
mechanisms to provide means for reservation of resources using LDP. This
document is a product of the Multiprotocol Label Switching Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3212.txt"
}

@TECHREPORT{rfc3213,
AUTHOR="J. Ash and M. Girish and E. Gray and B. Jamoussi and G. Wright",
TITLE="Applicability Statement for {CR-LDP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3213,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document discusses the applicability of Constraint-Based
LSP Setup using LDP. It discusses possible network applications,
extensions to Label Distribution Protocol (LDP) required to implement
constraint-based routing, guidelines for deployment and known
limitations of the protocol. This document is a prerequisite to
advancing CR-LDP on the standards track. This document is a product of
the Multiprotocol Label Switching Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3213.txt"
}

@TECHREPORT{rfc3214,
AUTHOR="J. Ash and Y. Lee and P. Ashwood-Smith and B. Jamoussi and D. Fedyk and D.
Skalecki and L. Li",
TITLE="{LSP} Modification Using {CR-LDP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3214,
PAGES=11,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document presents an approach to modify the bandwidth and
possibly other parameters of an established CR-LSP (Constraint-based
Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label
Distribution Protocol) without service interruption. After a CR-LSP is
set up, its bandwidth reservation may need to be changed by the network
operator, due to the new requirements for the traffic carried on that
CR-LSP. The LSP modification feature can be supported by CR-LDP by use
of the \_modify\_value for the \_action indicator flag\_ in the LSPID TLV.
This feature has application in dynamic network resources management
where traffic of different priorities and service classes is involved.
This document is a product of the Multiprotocol Label Switching Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3214.txt"
}

@TECHREPORT{rfc3215,
AUTHOR="C. Boscher and P. Cheval and L. T. Wu and E. Gray",
TITLE="{LDP} State Machine",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3215,
PAGES=78,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT={This document provides state machine tables for ATM
(Asynchronous Transfer Mode) switch LSRs. In the current LDP
specification, there is no state machine specified for processing LDP
messages. We think that defining a common state machine is very
important for interoperability between different LDP and CR-LDP
implementations. We begin in section 1 by defining a list of
terminologies. Then in section 2, we propose two sets of state machine
tables for ATM switch LSRs that use downstream-on-demand mode, one
method can be used for non-vc merge capable ATM LSRs, while the other
one can be used for the vc-merge capable ATM LSRs. In section 3, we
provides a state machine for downstream unsolicited mode ATM LSRs. We
focus on the LDP state machines and the associated control blocks used
for establishing and maintaining LSPs. We do not describe state machines
for the {"}LDP controller{"} that is in charge of LDP session
initialization, address mapping messages management, routing interface,
etc. that is defined in the LDP specification. Even though the state
machines in this document are specific for ATM-LSR, they can be easily
adapted for other types of LSRs. This document is a product of the
Multiprotocol Label Switching Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3215.txt"
}

@TECHREPORT{rfc3218,
AUTHOR="E. Rescorla",
TITLE="Preventing the Million Message Attack on Cryptographic Message Syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3218,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This memo describes a strategy for resisting the Million
Message Attack. This document is a product of the S/MIME Mail Security
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3218.txt"
}

@TECHREPORT{rfc3219,
AUTHOR="J. Rosenberg and H. F. Salama and M. Squire",
TITLE="Telephony Routing over {IP} {(TRIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3219,
PAGES=79,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document presents the Telephony Routing over IP (TRIP).
TRIP is a policy driven inter-administrative domain protocol for
advertising the reachability of telephony destinations between location
servers, and for advertising attributes of the routes to those
destinations. TRIP's operation is independent of any signaling protocol,
hence TRIP can serve as the telephony routing protocol for any signaling
protocol. The Border Gateway Protocol (BGP-4) is used to distribute
routing information between administrative domains. TRIP is used to
distribute telephony routing information between telephony
administrative domains. The similarity between the two protocols is
obvious, and hence TRIP is modeled after BGP-4. This document is a
product of the IP Telephony Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3219.txt"
}

@TECHREPORT{rfc3220,
EDITOR="C. E. Perkins",
TITLE="{IP} Mobility Support for {IPv4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3220,
PAGES=98,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document specifies protocol enhancements that allow
transparent routing of IP datagrams to mobile nodes in the Internet.
Each mobile node is always identified by its home address, regardless of
its current point of attachment to the Internet. While situated away
from its home, a mobile node is also associated with a care-of address,
which provides information about its current point of attachment to the
Internet. The protocol provides for registering the care-of address with
a home agent. The home agent sends datagrams destined for the mobile
node through a tunnel to the care-of address. After arriving at the end
of the tunnel, each datagram is then delivered to the mobile node. This
document is a product of the IP Routing for Wireless/Mobile Hosts
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3220.txt"
}

@TECHREPORT{rfc3224,
AUTHOR="E. Guttman",
TITLE="Vendor Extensions for Service Location Protocol, Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3224,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT={This document specifies how the features of the Service
Location Protocol, Version 2 allow for vendor extensibility safely, with
no possibility of collisions. The specification introduces a new SLPv2
extension: The Vendor Opaque Extension. While proprietary protocol
extensions are not encouraged by IETF standards, it is important that
they not hinder interoperability of compliant implementations when they
are undertaken. This document udpates RFC 2608, {"}The Service Location
Protocol.{"}},
URL="http://www.rfc-editor.org/rfc/rfc3224.txt"
}

@TECHREPORT{rfc3227,
AUTHOR="D. P. Brezinski and T. Killalea",
TITLE="Guidelines for Evidence Collection and Archiving",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3227,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT={A {"}security incident{"} as defined in the {"}Internet Security
Glossary{"}, RFC 2828, is a security-relevant system event in which the
system's security policy is disobeyed or otherwise breached. The purpose
of this document is to provide System Administrators with guidelines on
the collection and archiving of evidence relevant to such a security
incident. If evidence collection is done correctly, it is much more
useful in apprehending the attacker, and stands a much greater chance of
being admissible in the event of a prosecution. This document is a
product of the G \& R for Security Incident Processing Working Group of
the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3227.txt"
}

@TECHREPORT{rfc3228,
AUTHOR="B. Fenner",
TITLE="{IANA} Considerations for {IPv4} Internet Group Management Protocol
{(IGMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3228,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT="This memo requests that the IANA create a registry for fields
in the IGMP (Internet Group Management Protocol) protocol header, and
provides guidance for the IANA to use in assigning parameters for those
fields. This document is a product of the Multicast \& Anycast Group
Membership Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3228.txt"
}

@TECHREPORT{rfc3229,
AUTHOR="J. C. Mogul and B. Krishnamurthy and F. Douglis and A. Feldmann and Y.
Goland and A. van Hoff and D. Hellerstein",
TITLE="Delta encoding in {HTTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3229,
PAGES=49,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT={This document describes how delta encoding can be supported as
a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport
Protocol) requests cause the retrieval of slightly modified instances of
resources for which the client already has a cache entry. Research has
shown that such modifying updates are frequent, and that the
modifications are typically much smaller than the actual entity. In such
cases, HTTP would make more efficient use of network bandwidth if it
could transfer a minimal description of the changes, rather than the
entire new instance of the resource. This is called {"}delta encoding.{"}},
URL="http://www.rfc-editor.org/rfc/rfc3229.txt"
}

@TECHREPORT{rfc3230,
AUTHOR="J. C. Mogul and Arthur van Hoff",
TITLE="Instance Digests in {HTTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3230,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="HTTP/1.1 defines a Content-MD5 header that allows a server to
include a digest of the response body. However, this is specifically
defined to cover the body of the actual message, not the contents of the
full file (which might be quite different, if the response is a
Content-Range, or uses a delta encoding). Also, the Content-MD5 is
limited to one specific digest algorithm; other algorithms, such as
SHA-1 (Secure Hash Standard), may be more appropriate in some
circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which
a client may request a digest. This document proposes HTTP extensions
that solve these problems.",
URL="http://www.rfc-editor.org/rfc/rfc3230.txt"
}

@TECHREPORT{rfc3231,
AUTHOR="D. Levi and J. Schoenwaelder",
TITLE="Definitions of Managed Objects for Scheduling Management Operations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3231,
PAGES=29,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes a set of managed objects that are
used to schedule management operations periodically or at specified
dates and times. This document obsoletes RFC 2591. This document is a
product of the Distrubuted Management Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3231.txt"
}

@TECHREPORT{rfc3232,
EDITOR="J. F. Reynolds",
TITLE="Assigned Numbers: {RFC} 1700 is Replaced by an On-line Database",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3232,
PAGES=3,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT={This memo obsoletes RFC 1700 (STD 2) {"}Assigned Numbers{"}, which
contained an October 1994 snapshot of assigned Internet protocol
parameters.},
URL="http://www.rfc-editor.org/rfc/rfc3232.txt"
}

@TECHREPORT{rfc3233,
AUTHOR="P. Hoffman and S. Bradner",
TITLE="Defining the {IETF}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3233,
PAGES=4,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT={This document gives a more concrete definition of {"}the IETF{"}
as it understood today. Many RFCs refer to {"}the IETF{"}. Many important
IETF documents speak of the IETF as if it were an already-defined
entity. However, no IETF document correctly defines what the IETF is.},
URL="http://www.rfc-editor.org/rfc/rfc3233.txt"
}

@TECHREPORT{rfc3234,
AUTHOR="B. E. Carpenter and S. Brim",
TITLE="Middleboxes: Taxonomy and Issues",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3234,
PAGES=27,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT={This document is intended as part of an IETF discussion about
{"}middleboxes{"} - defined as any intermediary box performing functions
apart from normal, standard functions of an IP router on the data path
between a source host and destination host. This document establishes a
catalogue or taxonomy of middleboxes, cites previous and current IETF
work concerning middleboxes, and attempts to identify some preliminary
conclusions. It does not, however, claim to be definitive.},
URL="http://www.rfc-editor.org/rfc/rfc3234.txt"
}

@TECHREPORT{rfc3235,
AUTHOR="D. Senie",
TITLE="Network Address Translator {(NAT)-Friendly} Application Design Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3235,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document discusses those things that application
designers might wish to consider when designing new protocols. While
many common Internet applications will operate cleanly in the presence
of Network Address Translators, others suffer from a variety of problems
when crossing these devices. Guidelines are presented herein to help
ensure new protocols and applications will, to the extent possible, be
compatible with NAT (Network Address Translation). This document is a
product of the Network Address Translators Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3235.txt"
}

@TECHREPORT{rfc3236,
AUTHOR="M. Baker and P. Stark",
TITLE="The 'application/xhtml+xml' Media Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3236,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document defines the 'application/xhtml+xml' MIME media
type for XHTML based markup languages; it is not intended to obsolete
any previous IETF documents, in particular RFC 2854 which registers
'text/html'.",
URL="http://www.rfc-editor.org/rfc/rfc3236.txt"
}

@TECHREPORT{rfc3237,
AUTHOR="M. Tuexen and Q. Xie and R. J. Stewart and M. Shore and L. Ong and J.
Loughney and M. Stillman",
TITLE="Requirements for Reliable Server Pooling",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3237,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document defines a basic set of requirements for reliable
server pooling. The goal of Reliable Server Pooling (RSerPool) is to
develop an architecture and protocols for the management and operation
of server pools supporting highly reliable applications, and for client
access mechanisms to a server pool. This document is a product of the
Reliable Server Pooling Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3237.txt"
}

@TECHREPORT{rfc3238,
AUTHOR="S. Floyd and L. Daigle",
TITLE="{IAB} Architectural and Policy Considerations for Open Pluggable Edge
Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3238,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=2002,
ABSTRACT="This document includes comments and recommendations by the IAB
on some architectural and policy issues related to the chartering of
Open Pluggable Edge Services (OPES) in the IETF. OPES are services that
would be deployed at application-level intermediaries in the network,
for example, at a web proxy cache between the origin server and the
client. These intermediaries would transform or filter content, with the
explicit consent of either the content provider or the end user. This
document is a product of the Internet Architecture Board.",
URL="http://www.rfc-editor.org/rfc/rfc3238.txt"
}

@TECHREPORT{rfc3239,
AUTHOR="C. Kugler and H. Lewis and T. Hastings",
TITLE="Internet Printing Protocol {(IPP):} Requirements for Job, Printer, and
Device Administrative Operations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3239,
PAGES=15,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT="This document specifies the requirements and uses cases for
some optional administrative operations for use with the Internet
Printing Protocol (IPP) version 1.0 and version 1.1. Some of these
administrative operations operate on the IPP Job and Printer objects.
The remaining operations operate on a new Device object that more
closely models a single output device. This document is a product of the
Internet Printing Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3239.txt"
}

@TECHREPORT{rfc3240,
AUTHOR="D. Clunie and E. Cordonnier",
TITLE="Digital Imaging and Communications in Medicine {(DICOM)} -
Application/dicom {MIME} Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3240,
PAGES=6,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT={This document describes the registration of the MIME sub-type
application/dicom (Digital Imaging and Communications in Medicine). The
baseline encoding is defined by the DICOM Standards Committee in
{"}Digital Imaging and Communications in Medicine{"}.},
URL="http://www.rfc-editor.org/rfc/rfc3240.txt"
}

@TECHREPORT{rfc3241,
AUTHOR="C. Bormann",
TITLE="Robust Header Compression {(ROHC)} over {PPP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3241,
PAGES=12,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document describes an option for negotiating the use of
robust header compression (ROHC) on IP datagrams transmitted over the
Point-to-Point Protocol (PPP). It defines extensions to the PPP Control
Protocols for IPv4 and IPv6. This document is a product of the Robust
Header Compression Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3241.txt"
}

@TECHREPORT{rfc3242,
AUTHOR="L-e. Jonsson and G. Pelletier",
TITLE="{RObust} Header Compression {(ROHC):} A {Link-Layer} Assisted Profile for
{IP/UDP/RTP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3242,
PAGES=21,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document defines a ROHC (Robust Header Compression)
profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram
Protocol/Real-Time Transport Protocol) packets, utilizing functionality
provided by the lower layers to increase compression efficiency by
completely eliminating the header for most packets during optimal
operation. The profile is built as an extension to the ROHC RTP profile.
It defines additional mechanisms needed in ROHC, states requirements on
the assisting layer to guarantee transparency, and specifies general
logic for compression and decompression making use of this header-free
packet. This document is a product of the Robust Header Compression
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3242.txt"
}

@TECHREPORT{rfc3243,
AUTHOR="L-e. Jonsson",
TITLE="{RObust} Header Compression {(ROHC):} Requirements and Assumptions for
0-byte {IP/UDP/RTP} Compression",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3243,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document contains requirements for the 0-byte IP/UDP/RTP
(Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol)
header compression scheme to be developed by the Robust Header
Compression (ROHC) Working Group. It also includes the basic assumptions
for the typical link layers over which 0-byte compression may be
implemented, and assumptions about its usage in general. This document
is a product of the Robust Header Compression Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3243.txt"
}

@TECHREPORT{rfc3244,
AUTHOR="M. Swift and J. Trostle and J. Brezak",
TITLE="Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3244,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=2002,
ABSTRACT="This memo specifies Microsoft's Windows 2000 Kerberos change
password and set password protocols. The Windows 2000 Kerberos change
password protocol interoperates with the original Kerberos change
password protocol. Change password is a request reply protocol that
includes a KRB\_PRIV message that contains the new password for the user.",
URL="http://www.rfc-editor.org/rfc/rfc3244.txt"
}

@TECHREPORT{rfc3245,
EDITOR="J. Klensin and Anton Riabov",
TITLE="The History and Context of Telephone Number Mapping {(ENUM)} Operational
Decisions: Informational Documents Contributed to {ITU-T} Study Group 2
{(SG2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3245,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=2002,
ABSTRACT={RFC 2916 assigned responsibility for a number of
administrative and operational details of Telephone Number Mapping
(ENUM) to the IAB. It also anticipated that ITU would take
responsibility for determining the legitimacy and appropriateness of
applicants for delegation of {"}country code{"}-level subdomains of the
top-level ENUM domain. Recently, three memos have been prepared for the
ITU-T Study Group 2 (SG2) to explain the background of, and reasoning
for, the relevant decisions. The IAB has also supplied a set of
procedural instructions to the RIPE NCC for implementation of their part
of the model. The content of the three memos is provided in this
document for the information of the IETF community.},
URL="http://www.rfc-editor.org/rfc/rfc3245.txt"
}

@TECHREPORT{rfc3246,
AUTHOR="B. S. Davie and A. Charny and J. W. R. and K. Blair Benson and J. Y. Le and
W. Courtney and S. Davari and V. Firoiu",
TITLE="An Expedited Forwarding {PHB} {(Per-Hop} Behavior)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3246,
PAGES=16,
DAYS=15,
MONTH=mar,
YEAR=2002,
ABSTRACT="This document defines a PHB (per-hop behavior) called
Expedited Forwarding (EF). The PHB is a basic building block in the
Differentiated Services architecture. EF is intended to provide a
building block for low delay, low jitter and low loss services by
ensuring that the EF aggregate is served at a certain configured rate.
This document obsoletes RFC 2598. This document is a product of the
Differentiated Services Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3246.txt"
}

@TECHREPORT{rfc3247,
AUTHOR="A. Charny and J. Bennet and K. Blair Benson and J. Boudec and A. Chiu and
W. Courtney and S. Davari and V. Firoiu",
TITLE="Supplemental Information for the New Definition of the {EF} {PHB}
(Expedited Forwarding {Per-Hop} Behavior)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3247,
PAGES=24,
DAYS=15,
MONTH=mar,
YEAR=2002,
ABSTRACT={This document was written during the process of clarification
of RFC 2598 {"}An Expedited Forwarding PHB{"} that led to the publication
of
revised specification of EF {"}An Expedited Forwarding PHB{"}. Its primary
motivation is providing additional explanation to the revised EF
definition and its properties. The document also provides additional
implementation examples and gives some guidance for computation of the
numerical parameters of the new definition for several well known
schedulers and router architectures. This document is a product of the
Differentiated Services Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3247.txt"
}

@TECHREPORT{rfc3248,
AUTHOR="G. Armitage and B. E. Carpenter and A. Casati and Jon Crowcroft and J. Y.
Halpern and B. Kumar and J. Schnizlein",
TITLE="A Delay Bound alternative revision of {RFC} 2598",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3248,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=2002,
ABSTRACT="For historical interest, this document captures the EF Design
Team's proposed solution, preferred by the original authors of RFC 2598
but not adopted by the working group in December 2000. The original
definition of EF was based on comparison of forwarding on an unloaded
network. This experimental Delay Bound (DB) PHB requires a bound on the
delay of packets due to other traffic in the network. At the Pittsburgh
IETF meeting in August 2000, the Differentiated Services working group
faced serious questions regarding RFC 2598 - the group's standards track
definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An
'EF Design Team' volunteered to develop a re-expression of RFC 2598,
bearing in mind the issues raised in the DiffServ group. At the San
Diego IETF meeting in December 2000 the DiffServ working group decided
to pursue an alternative re-expression of the EF PHB. This document is a
product of the Differentiated Services Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3248.txt"
}

@TECHREPORT{rfc3249,
AUTHOR="V. Cancio and M. Moldovan and H. Tamura and D. Wing",
TITLE="Implementers Guide for Facsimile Using Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3249,
PAGES=21,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document is intended for the implementers of software
that use email to send to facsimiles using RFC 2305 and 2532. This is an
informational document and its guidelines do not supersede the
referenced documents. This document is a product of the Internet Fax
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3249.txt"
}

@TECHREPORT{rfc3250,
AUTHOR="L. McIntyre and G. Parsons and J. Rafferty",
TITLE="Tag Image File Format Fax eXtended {(TIFF-FX)} - image/tiff-fx {MIME}
Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3250,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document describes the registration of the MIME sub-type
image/tiff-fx. The encodings are defined by File Format for Internet Fax
and its extensions. This document is a product of the Internet Fax
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3250.txt"
}

@TECHREPORT{rfc3251,
AUTHOR="B. Rajagopalan",
TITLE="Electricity over {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3251,
PAGES=9,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT={Mostly Pointless Lamp Switching (MPLampS) is an architecture
for carrying electricity over IP (with an MPLS control plane). According
to our marketing department, MPLampS has the potential to dramatically
lower the price, ease the distribution and usage, and improve the
manageability of delivering electricity. This document is motivated by
such work as SONET/SDH over IP/MPLS (with apologies to the authors).
Readers of the previous work have been observed scratching their heads
and muttering, {"}What next?{"}. This document answers that question. This
document has also been written as a public service. The {"}Sub-IP{"} area
has been formed to give equal opportunity to those working on
technologies outside of traditional IP networking to write complicated
IETF documents. There are possibly many who are wondering how to exploit
this opportunity and attain high visibility. Towards this goal, we see
the topics of {"}foo-over-MPLS{"} (or MPLS control for random technologies)
as highly amenable for producing a countless number of unimplementable
documents. This document illustrates the key ingredients that go into
producing any {"}foo-over-MPLS{"} document and may be used as a template
for
all such work.},
URL="http://www.rfc-editor.org/rfc/rfc3251.txt"
}

@TECHREPORT{rfc3252,
AUTHOR="H. Kennedy",
TITLE="Binary Lexical Octet Ad-hoc Transport",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3252,
PAGES=16,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document defines a reformulation of IP and two transport
layer protocols (TCP and UDP) as XML applications.",
URL="http://www.rfc-editor.org/rfc/rfc3252.txt"
}

@TECHREPORT{rfc3253,
AUTHOR="G. Clemm and J. Amsden and T. Ellison and C. Kaler and J. Whitehead",
TITLE="Versioning Extensions to {WebDAV} (Web Distributed Authoring and
Versioning)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3253,
PAGES=118,
DAYS=15,
MONTH=mar,
YEAR=2002,
ABSTRACT="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. This document is a product of the Web Versioning
and Configuration Management Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3253.txt"
}

@TECHREPORT{rfc3254,
AUTHOR="H. Alvestrand",
TITLE="Definitions for talking about directories",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3254,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT={When discussing systems for making information accessible
through the Internet in standardized ways, it may be useful if the
people who are discussing it have a common understanding of the terms
they use. For example, a reference to this document would give one the
power to agree that the DNS (Domain Name System) is a global lookup
repository with perimeter integrity and loose, converging consistency.
On the other hand, a LDAP (Lightweight Directory Access Protocol)
directory server is a local, centralized repository with both lookup and
search capability. This document discusses one group of such systems
which is known under the term, {"}directories{"}.},
URL="http://www.rfc-editor.org/rfc/rfc3254.txt"
}

@TECHREPORT{rfc3255,
AUTHOR="N. Jones and C. Murton",
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",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3255,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document describes an extension to the mapping of
Point-to-Point Protocol (PPP) into Synchronous Optical
NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of
SONET/SDH SPE/VC virtual concatenation and the use of both high order
and low order payloads. This document is a product of the Point-to-Point
Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3255.txt"
}

@TECHREPORT{rfc3256,
AUTHOR="D. W. Jones and R. Woundy",
TITLE="The {DOCSIS} {(Data-Over-Cable} Service Interface Specifications) Device
Class {DHCP} (Dynamic Host Configuration Protocol) Relay Agent Information
Sub-option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3256,
PAGES=5,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT={This document proposes a new sub-option to the DHCP (Dynamic
Host Configuration Protocol) Relay Agent Information Option. This new
sub-option is for use with DOCSIS (Data-Over-Cable Service Interface
Specifications) cable modems and describes a {"}device class{"} to which
the
cable modem belongs. The cable modem signals its device class
information to the Relay Agent using DOCSIS signaling, and the Relay
Agent forwards the device class information to the DHCP Server which can
then make a policy decision based on it. This document is a product of
the Dynamic Host Configuration Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3256.txt"
}

@TECHREPORT{rfc3257,
AUTHOR="L. Coene",
TITLE="Stream Control Transmission Protocol Applicability Statement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3257,
PAGES=13,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document describes the applicability of the Stream
Control Transmission Protocol (SCTP). It also contrasts SCTP with the
two dominant transport protocols, User Datagram Protocol (UDP) \&
Transmission Control Protocol (TCP), and gives some guidelines for when
best to use SCTP and when not best to use SCTP. This document is a
product of the Signaling Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3257.txt"
}

@TECHREPORT{rfc3258,
AUTHOR="T. Hardie",
TITLE="Distributing Authoritative Name Servers via Shared Unicast Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3258,
PAGES=11,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This memo describes a set of practices intended to enable an
authoritative name server operator to provide access to a single named
server in multiple locations. The primary motivation for the development
and deployment of these practices is to increase the distribution of
Domain Name System (DNS) servers to previously under-served areas of the
network topology and to reduce the latency for DNS query responses in
those areas. This document is a product of the Domain Name Server
Operations Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3258.txt"
}

@TECHREPORT{rfc3259,
AUTHOR="J. Ott and C. E. Perkins and D. Kutscher",
TITLE="A Message Bus for Local Coordination",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3259,
PAGES=39,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="The local Message Bus (Mbus) is a light-weight
message-oriented coordination protocol for group communication between
application components. The Mbus provides automatic location of
communication peers, subject based addressing, reliable message transfer
and different types of communication schemes. The protocol is layered on
top of IP multicast and is specified for IPv4 and IPv6. The IP multicast
scope is limited to link-local multicast. This document specifies the
Mbus protocol, i.e., message syntax, addressing and transport
mechanisms. This document is a product of the Multiparty Multimedia
Session Control Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3259.txt"
}

@TECHREPORT{rfc3260,
AUTHOR="D. Grossman",
TITLE="New Terminology and Clarifications for Diffserv",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3260,
PAGES=10,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This memo captures Diffserv working group agreements
concerning new and improved terminology, and provides minor technical
clarifications. It is intended to update RFC 2474, RFC 2475 and RFC
2597. When RFCs 2474 and 2597 advance on the standards track, and RFC
2475 is updated, it is intended that the revisions in this memo will be
incorporated, and that this memo will be obsoleted by the new RFCs. This
document is a product of the Differentiated Services Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3260.txt"
}

@TECHREPORT{rfc3261,
AUTHOR="J. Rosenberg and Henning Schulzrinne and G. Camarillo and A. R. Johnston
and J. Peterson and R. Sparks and M. Handley and Eve M Schooler",
TITLE="{SIP:} Session Initiation Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3261,
PAGES=269,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document describes Session Initiation Protocol (SIP), an
application-layer control (signaling) protocol for creating, modifying,
and terminating sessions with one or more participants. These sessions
include Internet telephone calls, multimedia distribution, and
multimedia conferences. SIP invitations used to create sessions carry
session descriptions that allow participants to agree on a set of
compatible media types. SIP makes use of elements called proxy servers
to help route requests to the user's current location, authenticate and
authorize users for services, implement provider call-routing policies,
and provide features to users. SIP also provides a registration function
that allows users to upload their current locations for use by proxy
servers. SIP runs on top of several different transport protocols. This
document is a product of the Session Initiation Protocol Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3261.txt"
}

@TECHREPORT{rfc3262,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="Reliability of Provisional Responses in Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3262,
PAGES=14,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document specifies an extension to the Session Initiation
Protocol (SIP) providing reliable provisional response messages. This
extension uses the option tag 100rel and defines the Provisional
Response ACKnowledgement (PRACK) method. This document is a product of
the Session Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3262.txt"
}

@TECHREPORT{rfc3263,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="Session Initiation Protocol {(SIP):} Locating {SIP} Servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3263,
PAGES=17,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="The Session Initiation Protocol (SIP) uses DNS procedures to
allow a client to resolve a SIP Uniform Resource Identifier (URI) into
the IP address, port, and transport protocol of the next hop to contact.
It also uses DNS to allow a server to send a response to a backup client
if the primary client has failed. This document describes those DNS
procedures in detail. This document is a product of the Session
Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3263.txt"
}

@TECHREPORT{rfc3264,
AUTHOR="J. Rosenberg and Henning Schulzrinne",
TITLE="An {Offer/Answer} Model with Session Description Protocol {(SDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3264,
PAGES=25,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document defines a mechanism by which two entities can
make use of the Session Description Protocol (SDP) to arrive at a common
view of a multimedia session between them. In the model, one participant
offers the other a description of the desired session from their
perspective, and the other participant answers with the desired session
from their perspective. This offer/answer model is most useful in
unicast sessions where information from both participants is needed for
the complete view of the session. The offer/answer model is used by
protocols like the Session Initiation Protocol (SIP). This document is a
product of the Session Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3264.txt"
}

@TECHREPORT{rfc3265,
AUTHOR="Adam Roach",
TITLE="Session Initiation Protocol {({SIP})-Specific} Event Notification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3265,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document describes an extension to the Session Initiation
Protocol (SIP). The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred. Concrete uses
of the mechanism described in this document may be standardized in the
future. Note that the event notification mechanisms defined herein are
NOT intended to be a general-purpose infrastructure for all classes of
event subscription and notification. This document is a product of the
Session Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3265.txt"
}

@TECHREPORT{rfc3266,
AUTHOR="S. Olson and G. Camarillo and A. B. Roach",
TITLE="Support for {IPv6} in Session Description Protocol {(SDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3266,
PAGES=5,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document describes the use of Internet Protocol Version 6
(IPv6) addresses in conjunction with the Session Description Protocol
(SDP). Specifically, this document clarifies existing text in SDP with
regards to the syntax of IPv6 addresses. This document is a product of
the Session Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3266.txt"
}

@TECHREPORT{rfc3267,
AUTHOR="J. Sjoberg and M. Westerlund and A. Lakaniemi and Q. Xie",
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",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3267,
PAGES=49,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document specifies a real-time transport protocol (RTP)
payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive
Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format
is designed to be able to interoperate with existing AMR and AMR-WB
transport formats on non-IP networks. In addition, a file format is
specified for transport of AMR and AMR-WB speech data in storage mode
applications such as email. Two separate MIME type registrations are
included, one for AMR and one for AMR-WB, specifying use of both the RTP
payload format and the storage format. This document is a product of the
Audio/Video Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3267.txt"
}

@TECHREPORT{rfc3268,
AUTHOR="P. Chown",
TITLE="Advanced Encryption Standard {(AES)} Ciphersuites for Transport Layer
Security {(TLS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3268,
PAGES=7,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document proposes several new ciphersuites. At present,
the symmetric ciphers supported by Transport Layer Security (TLS) are
RC2, RC4, International Data Encryption Algorithm (IDEA), Data
Encryption Standard (DES), and triple DES. The protocol would be
enhanced by the addition of Advanced Encryption Standard (AES)
ciphersuites.",
URL="http://www.rfc-editor.org/rfc/rfc3268.txt"
}

@TECHREPORT{rfc3269,
AUTHOR="R. Kermode and L. Vicisano",
TITLE="Author Guidelines for Reliable Multicast Transport {(RMT)} Building Blocks
and Protocol Instantiation documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3269,
PAGES=12,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document provides general guidelines to assist the
authors of Reliable Multicast Transport (RMT) building block and
protocol instantiation definitions. The purpose of these guidelines is
to ensure that any building block and protocol instantiation definitions
produced contain sufficient information to fully explain their operation
and use. In addition these guidelines provide directions to specify
modular and clearly defined RMT building blocks and protocol
instantiations that can be refined and augmented to safely create new
protocols for use in new scenarios for which any existing protocols were
not designed. This document is a product of the Reliable Multicast
Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3269.txt"
}

@TECHREPORT{rfc3270,
AUTHOR="F. Le Faucheur and L. T. Wu and B. S. Davie and S. Davari and P. Vaananen
and R. Krishnan and P. Cheval and J. Heinanen",
TITLE="{Multi-Protocol} Label Switching {(MPLS)} Support of Differentiated
Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3270,
PAGES=64,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This document defines a flexible solution for support of
Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching
(MPLS) networks. This solution allows the MPLS network administrator to
select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label
Switched Paths (LSPs) so that he/she can best match the Diff-Serv,
Traffic Engineering and protection objectives within his/her particular
network. For instance, this solution allows the network administrator to
decide whether different sets of BAs are to be mapped onto the same LSP
or mapped onto separate LSPs. This document is a product of the
Multiprotocol Label Switching Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3270.txt"
}

@TECHREPORT{rfc3271,
AUTHOR="V. G. Cerf",
TITLE="The Internet is for Everyone",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3271,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document expresses the Internet Society's ideology that
the Internet really is for everyone. However, it will only be such if we
make it so.",
URL="http://www.rfc-editor.org/rfc/rfc3271.txt"
}

@TECHREPORT{rfc3272,
AUTHOR="Daniel O. Awduche and A. Chiu and A. I. Elwalid and I. Widjaja and X. Xiao",
TITLE="Overview and Principles of Internet Traffic Engineering",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3272,
PAGES=71,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This memo describes the principles of Traffic Engineering (TE)
in the Internet. The document is intended to promote better
understanding of the issues surrounding traffic engineering in IP
networks, and to provide a common basis for the development of traffic
engineering capabilities for the Internet. The principles,
architectures, and methodologies for performance evaluation and
performance optimization of operational IP networks are discussed
throughout this document. This document is a product of the Internet
Traffic Engineering Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3272.txt"
}

@TECHREPORT{rfc3273,
AUTHOR="S. Waldbusser",
TITLE="Remote Network Monitoring Management Information Base for High Capacity
Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3273,
PAGES=77,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring (RMON) devices for use on high speed networks. This document
contains a MIB Module that defines these new objects and also contains
definitions of some updated objects from the RMON-MIB in RFC 2819 and
the RMON2-MIB in RFC 2021. This document is a product of the Remote
Network Monitoring Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3273.txt"
}

@TECHREPORT{rfc3274,
AUTHOR="P. Gutmann",
TITLE="Compressed Data Content Type for Cryptographic Message Syntax {(CMS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3274,
PAGES=6,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document defines a format for using compressed data as a
Cryptographic Message Syntax (CMS) content type. Compressing data before
transmission provides a number of advantages, including the elimination
of data redundancy which could help an attacker, speeding up processing
by reducing the amount of data to be processed by later steps (such as
signing or encryption), and reducing overall message size. Although
there have been proposals for adding compression at other levels (for
example at the MIME or SSL level), these don't address the problem of
compression of CMS content unless the compression is supplied by an
external means (for example by intermixing MIME and CMS). This document
is a product of the S/MIME Mail Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3274.txt"
}

@TECHREPORT{rfc3275,
AUTHOR="D. Eastlake 3rd and J. Reagle and D. Solo",
TITLE="(Extensible Markup Language) {XML-Signature} Syntax and Processing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3275,
PAGES=73,
DAYS=15,
MONTH=mar,
YEAR=2002,
ABSTRACT="This document specifies XML (Extensible Markup Language)
digital signature processing rules and syntax. XML Signatures provide
integrity, message authentication, and/or signer authentication services
for data of any type, whether located within the XML that includes the
signature or elsewhere. This document is a product of the XML Digital
Signatures Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3275.txt"
}

@TECHREPORT{rfc3276,
AUTHOR="B. Ray and R. Abbi",
TITLE="Definitions of Managed Objects for High {Bit-Rate} {DSL} - 2nd generation
{(HDSL2)} and {Single-Pair} {High-Speed} Digital Subscriber Line {(SHDSL)}
Lines Processing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3276,
PAGES=66,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This document defines a portion of the Management Information
Base (MIB) module for use with network management protocols in the
Internet community. In particular, it describes objects used for
managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair
High-Speed Digital Subscriber Line (SHDSL) interfaces. This document is
a product of the ADSL MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3276.txt"
}

@TECHREPORT{rfc3277,
AUTHOR="D. McPherson",
TITLE="Intermediate System to Intermediate System {(IS-IS)} Transient Blackhole
Avoidance",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3277,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document describes a simple, interoperable mechanism that
can be employed in Intermediate System to Intermediate System (IS-IS)
networks in order to decrease the data loss associated with
deterministic blackholing of packets during transient network
conditions. The mechanism proposed here requires no IS-IS protocol
changes and is completely interoperable with the existing IS-IS
specification. This document is a product of the IS-IS for IP Internets
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3277.txt"
}

@TECHREPORT{rfc3278,
AUTHOR="S. Blake-Wilson and D. M. Brown and P. Lambert",
TITLE="Use of Elliptic Curve Cryptography {(ECC)} Algorithms in Cryptographic
Message Syntax {(CMS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3278,
PAGES=16,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document describes how to use Elliptic Curve Cryptography
(ECC) public-key algorithms in the Cryptographic Message Syntax (CMS).
The ECC algorithms support the creation of digital signatures and the
exchange of keys to encrypt or authenticate content. The definition of
the algorithm processing is based on the ANSI X9.62 standard, developed
by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1
standard. The readers attention is called to the Intellectual Property
Rights section at the end of this document. This document is a product
of the S/MIME Mail Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3278.txt"
}

@TECHREPORT{rfc3279,
AUTHOR="L. Bassham and W. Polk and R. Housley",
TITLE="Algorithms and Identifiers for the Internet {X.509} Public Key
Infrastructure Certificate and Certificate Revocation List {(CRL)} Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3279,
PAGES=27,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This document specifies algorithm identifiers and ASN.1
encoding formats for digital signatures and subject public keys used in
the Internet X.509 Public Key Infrastructure (PKI). Digital signatures
are used to sign certificates and certificate revocation list (CRLs).
Certificates include the public key of the named subject. This document
is a product of the Internet X.509 Public Key Infrastructure (PKIX)
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3279.txt"
}

@TECHREPORT{rfc3280,
AUTHOR="R. Housley and W. Polk and W. Ford and D. Solo",
TITLE="Internet {X.509} Public Key Infrastructure Certificate and Certificate
Revocation List {(CRL)} Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3280,
PAGES=129,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This memo profiles the X.509 v3 certificate and X.509 v2
Certificate Revocation List (CRL) for use in the Internet. An overview
of this approach and model are provided as an introduction. The X.509 v3
certificate format is described in detail, with additional information
regarding the format and semantics of Internet name forms. Standard
certificate extensions are described and two Internet-specific
extensions are defined. A set of required certificate extensions is
specified. The X.509 v2 CRL format is described in detail, and required
extensions are defined. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in
the appendices. This document is a product of the Internet X.509 Public
Key Infrastructure (PKIX) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3280.txt"
}

@TECHREPORT{rfc3281,
AUTHOR="S. Farrell and R. Housley",
TITLE="An Internet Attribute Certificate Profile for Authorization",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3281,
PAGES=40,
DAYS=15,
MONTH=apr,
YEAR=2002,
ABSTRACT="This specification defines a profile for the use of X.509
Attribute Certificates in Internet Protocols. Attribute certificates may
be used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is to
establish a common baseline for generic applications requiring broad
interoperability as well as limited special purpose requirements. The
profile places emphasis on attribute certificate support for Internet
electronic mail, IPSec, and WWW security applications. This document is
a product of the Public-Key Infrastructure (X.509) Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3281.txt"
}

@TECHREPORT{rfc3282,
AUTHOR="H. Alvestrand",
TITLE="Content Language Headers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3282,
PAGES=8,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT={This document defines a {"}Content-language:{"} header, for use in
cases where one desires to indicate the language of something that has
RFC 822-like headers, like MIME body parts or Web documents, and an
{"}Accept-Language:{"} header for use in cases where one wishes to indicate
one's preferences with regard to language.},
URL="http://www.rfc-editor.org/rfc/rfc3282.txt"
}

@TECHREPORT{rfc3283,
AUTHOR="B. Mahoney and G. Babics and A. Taler",
TITLE="Guide to Internet Calendaring",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3283,
PAGES=16,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT={This document describes the various Internet calendaring and
scheduling standards and works in progress, and the relationships
between them. Its intent is to provide a context for these documents,
assist in their understanding, and potentially aid in the design of
standards-based calendaring and scheduling systems. The standards
addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447
(iMIP). The work in progress addressed is {"}Calendar Access Protocol{"}
(CAP). This document also describes issues and problems that are not
solved by these protocols, and that could be targets for future work.},
URL="http://www.rfc-editor.org/rfc/rfc3283.txt"
}

@TECHREPORT{rfc3284,
AUTHOR="D. Korn and J. MacDonald and J. C. Mogul and K. Vo",
TITLE="The {VCDIFF} Generic Differencing and Compression Data Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3284,
PAGES=29,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This memo describes VCDIFF, a general, efficient and portable
data format suitable for encoding compressed and/or differencing data so
that they can be easily transported among computers.",
URL="http://www.rfc-editor.org/rfc/rfc3284.txt"
}

@TECHREPORT{rfc3285,
AUTHOR="M. Gahrns and T. Hain",
TITLE="Using Microsoft Word to create Internet Drafts and {RFCs}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3285,
PAGES=19,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This document describes the steps to configure the Microsoft
Word application to produce documents in Internet Draft and RFC format.",
URL="http://www.rfc-editor.org/rfc/rfc3285.txt"
}

@TECHREPORT{rfc3286,
AUTHOR="L. Ong and J. Yoakum",
TITLE="An Introduction to the Stream Control Transmission Protocol {(SCTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3286,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This document provides a high level introduction to the
capabilities supported by the Stream Control Transmission Protocol
(SCTP). It is intended as a guide for potential users of SCTP as a
general purpose transport protocol.",
URL="http://www.rfc-editor.org/rfc/rfc3286.txt"
}

@TECHREPORT{rfc3287,
AUTHOR="A. Bierman",
TITLE="Remote Monitoring {MIB} Extensions for Differentiated Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3287,
PAGES=120,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
monitoring Differentiated Services (DS) Codepoint usage in packets which
contain a DS field, utilizing the monitoring framework defined in the
RMON-2 (Remote Network Monitoring Management Version 2) MIB. This
document is a product of the Remote Network Monitoring Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3287.txt"
}

@TECHREPORT{rfc3288,
AUTHOR="E. O'Tuathail and M. P. Rose",
TITLE="Using the Simple Object Access Protocol {(SOAP)} in Blocks Extensible
Exchange Protocol {(BEEP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3288,
PAGES=20,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="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. 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.",
URL="http://www.rfc-editor.org/rfc/rfc3288.txt"
}

@TECHREPORT{rfc3289,
AUTHOR="F. Baker and K. Chan and A. J. Smith",
TITLE="Management Information Base for the Differentiated Services Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3289,
PAGES=116,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This memo describes an SMIv2 (Structure of Management
Information version 2) MIB for a device implementing the Differentiated
Services Architecture. It may be used both for monitoring and
configuration of a router or switch capable of Differentiated Services
functionality. This document is a product of the Differentiated Services
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3289.txt"
}

@TECHREPORT{rfc3290,
AUTHOR="Y. Bernet and S. Blake and D. Grossman and A. J. Smith",
TITLE="An Informal Management Model for Diffserv Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3290,
PAGES=56,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This document proposes an informal management model of
Differentiated Services (Diffserv) routers for use in their management
and configuration. This model defines functional datapath elements
(e.g., classifiers, meters, actions, marking, absolute dropping,
counting, multiplexing), algorithmic droppers, queues and schedulers. It
describes possible configuration parameters for these elements and how
they might be interconnected to realize the range of traffic
conditioning and per-hop behavior (PHB) functionalities described in the
Diffserv Architecture. This document is a product of the Differentiated
Services Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3290.txt"
}

@TECHREPORT{rfc3291,
AUTHOR="M. Daniele and B. Haberman and S. Routhier and J. Schoenwaelder",
TITLE="Textual Conventions for Internet Network Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3291,
PAGES=20,
DAYS=15,
MONTH=may,
YEAR=2002,
ABSTRACT="This MIB module defines textual conventions to represent
commonly used Internet network layer addressing information. The intent
is that these textual conventions (TCs) will be imported and used in MIB
modules that would otherwise define their own representations. This
document obsoletes RFC 2851. This document is a product of the
Operations and Management Open Area Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3291.txt"
}

@TECHREPORT{rfc3292,
AUTHOR="A. Doria and F. Hellstrand and K. Sundell and T. Worster",
TITLE="General Switch Management Protocol {(GSMP)} {V3}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3292,
PAGES=137,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document describes the General Switch Management Protocol
Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one
or more external switch controllers to establish and maintain the state
of a label switch such as, an ATM, frame relay or MPLS switch. The
GSMPv3 allows control of both unicast and multicast switch connection
state as well as control of switch system resources and QoS features.
This document is a product of the General Switch Management Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3292.txt"
}

@TECHREPORT{rfc3293,
AUTHOR="T. Worster and A. Doria and J. Buerkle",
TITLE="General Switch Management Protocol {(GSMP)} Packet Encapsulations for
Asynchronous Transfer Mode {(ATM),} Ethernet and Transmission Control
Protocol {(TCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3293,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This memo specifies the encapsulation of GSMP (General Switch
Management Protocol) packets in ATM (Asynchronous Transfer Mode),
Ethernet and TCP (Transmission Control Protocol). This document is a
product of the General Switch Management Protocol Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3293.txt"
}

@TECHREPORT{rfc3294,
AUTHOR="A. Doria and K. Sundell",
TITLE="General Switch Management Protocol {(GSMP)} Applicability",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3294,
PAGES=9,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This memo provides an overview of the GSMP (General Switch
Management Protocol) and includes information relating to its deployment
in a IP network in an MPLS environment. It does not discuss deployment
in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet
configuration.",
URL="http://www.rfc-editor.org/rfc/rfc3294.txt"
}

@TECHREPORT{rfc3295,
AUTHOR="H. Sjostrand and J. Buerkle and B. Srinivasan",
TITLE="Definitions of Managed Objects for the General Switch Management Protocol
{(GSMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3295,
PAGES=47,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for the use with the network management protocols in the Internet
community. In particular, it describes managed objects for the General
Switch Management Protocol (GSMP). This document is a product of the
General Switch Management Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3295.txt"
}

@TECHREPORT{rfc3296,
AUTHOR="K. Zeilenga",
TITLE="Named Subordinate References in Lightweight Directory Access Protocol
{(LDAP)} Directories",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3296,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT="This document details schema and protocol elements for
representing and managing named subordinate references in Lightweight
Directory Access Protocol (LDAP) Directories.",
URL="http://www.rfc-editor.org/rfc/rfc3296.txt"
}

@TECHREPORT{rfc3297,
AUTHOR="G. Klyne and R. Iwazaki and D. H. Crocker",
TITLE="Content Negotiation for Messaging Services based on Email",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3297,
PAGES=46,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT="This memo describes a content negotiation mechanism for
facsimile, voice and other messaging services that use Internet email.
Services such as facsimile and voice messaging need to cope with new
message content formats, yet need to ensure that the content of any
given message is renderable by the receiving agent. The mechanism
described here aims to meet these needs in a fashion that is fully
compatible with the current behaviour and expectations of Internet
email. This document is a product of the Internet Fax Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3297.txt"
}

@TECHREPORT{rfc3298,
AUTHOR="I. Faynberg and J. Gato and H. Lu and L. Slutsman",
TITLE="Service in the Public Switched Telephone {Network/Intelligent} Network
{(PSTN/IN)} Requesting {InTernet} Service {(SPIRITS)} Protocol Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3298,
PAGES=17,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT={This document describes the SPIRITS protocol requirements,
based on the architecture presented in RFC 3136. (SPIRITS stands for
{"}Service in the PSTN/IN Requesting InTernet Service{"}.) The purpose of
the protocol is to support services that originate in the Public
Switched Telephone Network (PSTN) and necessitate the interactions
between the PSTN and the Internet. Similarly, such services are called
SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery,
and Internet Call Forwarding are examples of SPIRIT services, but the
protocol is to define the building blocks from which many other services
can be built.) On the PSTN side, the SPIRITS services are initiated from
the Intelligent Network (IN) entities; the earlier IETF work on the
PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in
support of the services initiated the other way around--from the
Internet to PSTN. To this end, this document lists general requirements
for the SPIRITS protocol as well as those pertinent to IN, Wireless IN,
and PINT building blocks. The document also presents the SPIRITS WG
consensus on the choice of the SPIRITS signaling protocol. This document
is a product of the Service in the PSTN/IN Requesting InTernet Service
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3298.txt"
}

@TECHREPORT{rfc3300,
AUTHOR="J. F. Reynolds and R. Braden and S. Ginoza and  ",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3300,
PAGES=49,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This memo contains a snapshot of the state of standardization
of protocols used in the Internet as of October 24, 2002. It lists
official protocol standards and Best Current Practice RFCs; it is not a
complete index to the RFC series. The latest version of this memo is
designated STD 1.",
URL="http://www.rfc-editor.org/rfc/rfc3300.txt"
}

@TECHREPORT{rfc3301,
AUTHOR="Y. T'Joens and P. Crivellari and B. Sales",
TITLE="Layer Two Tunnelling Protocol {(L2TP):} {ATM} access network extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3301,
PAGES=19,
DAYS=15,
MONTH=jun,
YEAR=2002,
ABSTRACT="This document augments the procedures described in RFC 2661 to
further support ATM SVC (Switched Virtual Circuits) or PVC (Permanent
Virtual Circuits) based access networks. L2TP (Layer 2 Tunneling
Protocol) specifies a protocol for tunnelling PPP packets over packet
based networks and over IP networks in particular. L2TP supports remote
access by ISDN and PSTN networks. The extensions defined within this
document allow for asymmetric bi-directional call establishment and
service selection in the ATM access network.",
URL="http://www.rfc-editor.org/rfc/rfc3301.txt"
}

@TECHREPORT{rfc3302,
AUTHOR="G. Parsons and J. Rafferty",
TITLE="Tag Image File Format {(TIFF)} - image/tiff {MIME} Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3302,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document describes the registration of the MIME sub-type
image/tiff. This document refines an earlier sub-type registration in
RFC 1528. This document obsoletes RFC 2302. This document is a product
of the Internet Fax Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3302.txt"
}

@TECHREPORT{rfc3303,
AUTHOR="P. Srisuresh and J. Kuthan and J. Rosenberg and A. Molitor and A. Rayhan",
TITLE="Middlebox communication architecture and framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3303,
PAGES=34,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="A principal objective of this document is to describe the
underlying framework of middlebox communications (MIDCOM) to enable
complex applications through the middleboxes, seamlessly using a trusted
third party. This document and a companion document on MIDCOM
requirements ([REQMTS]) have been created as a precursor to rechartering
the MIDCOM working group. There are a variety of intermediate devices in
the Internet today that require application intelligence for their
operation. Datagrams pertaining to real-time streaming applications,
such as SIP and H.323, and peer-to-peer applications, such as Napster
and NetMeeting, cannot be identified by merely examining packet headers.
Middleboxes implementing Firewall and Network Address Translator
services typically embed application intelligence within the device for
their operation. The document specifies an architecture and framework in
which trusted third parties can be delegated to assist the middleboxes
to perform their operation, without resorting to embedding application
intelligence. Doing this will allow a middlebox to continue to provide
the services, while keeping the middlebox application agnostic. This
document is a product of the Middlebox Communication Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3303.txt"
}

@TECHREPORT{rfc3304,
AUTHOR="R P Swale and P. A. Mart and P. Sijben and S. Brim and M. Shore",
TITLE="Middlebox Communications (midcom) Protocol Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3304,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document specifies the requirements that the Middlebox
Communication (midcom) protocol must satisfy in order to meet the needs
of applications wishing to influence the middlebox function. These
requirements were developed with a specific focus on network address
translation and firewall middleboxes. This document is a product of the
Middlebox Communication Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3304.txt"
}

@TECHREPORT{rfc3305,
EDITOR="M. Mealling and R. Denenberg+",
TITLE="Report from the Joint {W3C/IETF} {URI} Planning Interest Group: Uniform
Resource Identifiers {(URIs),} {URLs,} and Uniform Resource Names {(URNs):}
Clarifications and Recommendations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3305,
PAGES=11,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document, a product of the W3C Uniform Resource
Identifier (URI) Interest Group, addresses and attempts to clarify
issues pertaining to URIs. This document addresses how URI space is
partitioned and the relationship between URIs, URLs, and URNs, describes
how URI schemes and URN namespaces ids are registered, and presents
recommendations for continued work on this subject.",
URL="http://www.rfc-editor.org/rfc/rfc3305.txt"
}

@TECHREPORT{rfc3306,
AUTHOR="B. Haberman and D. Thaler",
TITLE="{Unicast-Prefix-based} {IPv6} Multicast Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3306,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This specification defines an extension to the multicast
addressing architecture of the IP Version 6 protocol. The extension
presented in this document allows for unicast-prefix-based allocation of
multicast addresses. By delegating multicast addresses at the same time
as unicast prefixes, network operators will be able to identify their
multicast addresses without needing to run an inter-domain allocation
protocol. This document is a product of the IPNG Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3306.txt"
}

@TECHREPORT{rfc3307,
AUTHOR="B. Haberman",
TITLE="Allocation Guidelines for {IPv6} Multicast Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3307,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document specifies guidelines that must be implemented by
any entity responsible for allocating IPv6 multicast addresses. This
includes, but is not limited to, any documents or entities wishing to
assign permanent IPv6 multicast addresses, allocate dynamic IPv6
multicast addresses, and define permanent IPv6 multicast group
identifiers. The purpose of these guidelines is to reduce the
probability of IPv6 multicast address collision, not only at the IPv6
layer, but also at the link-layer of media that encode portions of the
IP layer address into the MAC layer address. This document is a product
of the Multicast-Address Allocation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3307.txt"
}

@TECHREPORT{rfc3308,
AUTHOR="P. Calhoun and W. Luo and D. McPherson and K. Peirce",
TITLE="Layer Two Tunneling Protocol {(L2TP)} Differentiated Services Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3308,
PAGES=10,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document describes mechanisms which enable the Layer Two
Tunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB)
code for the L2TP control connection, as well as individual sessions
within an L2TP tunnel. L2TP provides a standard method for tunneling PPP
packets. The current specification provides no provisions for supporting
Differentiated Services (diffserv) over the L2TP control connection or
subsequent data sessions. As a result, no standard mechanism currently
exists within L2TP to provide L2TP protocol negotiations for service
discrimination. This document is a product of the Layer Two Tunneling
Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3308.txt"
}

@TECHREPORT{rfc3309,
AUTHOR="J. Stone and R. J. Stewart and D. Otis",
TITLE="Stream Control Transmission Protocol {(SCTP)} Checksum Change",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3309,
PAGES=17,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="Stream Control Transmission Protocol (SCTP) currently uses an
Adler-32 checksum. For small packets Adler-32 provides weak detection of
errors. This document changes that checksum and updates SCTP to use a 32
bit CRC checksum. This document is a product of the Transport Area
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3309.txt"
}

@TECHREPORT{rfc3310,
AUTHOR="A. Niemi and J. Arkko and V. Torvinen",
TITLE="Hypertext Transfer Protocol {(HTTP)} Digest Authentication Using
Authentication and Key Agreement {(AKA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3310,
PAGES=18,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This memo specifies an Authentication and Key Agreement (AKA)
based one-time password generation mechanism for Hypertext Transfer
Protocol (HTTP) Digest access authentication. The HTTP Authentication
Framework includes two authentication schemes: Basic and Digest. Both
schemes employ a shared secret based mechanism for access
authentication. The AKA mechanism performs user authentication and
session key distribution in Universal Mobile Telecommunications System
(UMTS) networks. AKA is a challenge-response based mechanism that uses
symmetric cryptography. This document is a product of the Session
Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3310.txt"
}

@TECHREPORT{rfc3311,
AUTHOR="J. Rosenberg",
TITLE="The Session Initiation Protocol {(SIP)} {UPDATE} Method",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3311,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT="This specification defines the new UPDATE method for the
Session Initiation Protocol (SIP). UPDATE allows a client to update
parameters of a session (such as the set of media streams and their
codecs) but has no impact on the state of a dialog. In that sense, it is
like a re-INVITE, but unlike re-INVITE, it can be sent before the
initial INVITE has been completed. This makes it very useful for
updating session parameters within early dialogs.",
URL="http://www.rfc-editor.org/rfc/rfc3311.txt"
}

@TECHREPORT{rfc3312,
EDITOR="G. Camarillo and W. T. Marshall and J. Rosenberg",
TITLE="Integration of Resource Management and Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3312,
PAGES=30,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT="This document defines a generic framework for preconditions,
which are extensible through IANA registration. This document also
discusses how network quality of service can be made a precondition for
establishment of sessions initiated by the Session Initiation Protocol
(SIP). These preconditions require that the participant reserve network
resources before continuing with the session. We do not define new
quality of service reservation mechanisms; these preconditions simply
require a participant to use existing resource reservation mechanisms
before beginning the session. This document is a product of the Session
Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3312.txt"
}

@TECHREPORT{rfc3314,
EDITOR="M. Wasserman",
TITLE="Recommendations for {IPv6} in Third Generation Partnership Project {(3GPP)}
Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3314,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document contains recommendations from the Internet
Engineering Task Force (IETF) IPv6 Working Group to the Third Generation
Partnership Project (3GPP) community regarding the use of IPv6 in the
3GPP standards. Specifically, this document recommends that the 3GPP
specify that multiple prefixes may be assigned to each primary PDP
context, require that a given prefix must not be assigned to more than
one primary PDP context, and allow 3GPP nodes to use multiple
identifiers within those prefixes, including randomly generated
identifiers. The IPv6 Working Group supports the use of IPv6 within 3GPP
and offers these recommendations in a spirit of open cooperation between
the IPv6 Working Group and the 3GPP community. Since the original
publication of this document as an Internet-Draft, the 3GPP has adopted
the primary recommendations of this document. This document is a product
of the IP Version 6 Working Group Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3314.txt"
}

@TECHREPORT{rfc3323,
AUTHOR="J. Peterson",
TITLE="A Privacy Mechanism for the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3323,
PAGES=22,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT={This document defines new mechanisms for the Session
Initiation Protocol (SIP) in support of privacy. Specifically,
guidelines are provided for the creation of messages that do not divulge
personal identity information. A new {"}privacy service{"} logical role for
intermediaries is defined to answer some privacy requirements that user
agents cannot satisfy themselves. Finally, means are presented by which
a user can request particular functions from a privacy service. This
document is a product of the Session Initiation Proposal Investigation
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3323.txt"
}

@TECHREPORT{rfc3324,
AUTHOR="M. Watson",
TITLE="Short Term Requirements for Network Asserted Identity",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3324,
PAGES=11,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="A Network Asserted Identity is an identity initially derived
by a Session Initiation Protocol (SIP) network intermediary as a result
of an authentication process. This document describes short term
requirements for the exchange of Network Asserted Identities within
networks of securely interconnected trusted nodes and to User Agents
securely connected to such networks. There is no requirement for
identities asserted by a UA in a SIP message to be anything other than
the user's desired alias. This document is a product of the Session
Initiation Proposal Investigation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3324.txt"
}

@TECHREPORT{rfc3325,
AUTHOR="C. Jennings and J. Peterson and M. Watson",
TITLE="Private Extensions to the Session Initiation Protocol {(SIP)} for Asserted
Identity within Trusted Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3325,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document describes private extensions to the Session
Initiation Protocol (SIP) that enable a network of trusted SIP servers
to assert the identity of authenticated users, and the application of
existing privacy mechanisms to the identity problem. The use of these
extensions is only applicable inside an administrative domain with
previously agreed-upon policies for generation, transport and usage of
such information. This document does NOT offer a general privacy or
identity model suitable for use between different trust domains, or use
in the Internet at large. This document is a product of the Session
Initiation Protocol Working Group and the Session Initiation Proposal
Investigation Working Groups of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3325.txt"
}

@TECHREPORT{rfc3326,
AUTHOR="Henning Schulzrinne and D. Oran and G. Camarillo",
TITLE="The Reason Header Field for the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3326,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT={For creating services, it is often useful to know why a
Session Initiation Protocol (SIP) request was issued. This document
defines a header field, Reason, that provides this information. The
Reason header field is also intended to be used to encapsulate a final
status code in a provisional response. This functionality is needed to
resolve the {"}Heterogeneous Error Response Forking Problem{"}, or HERFP.
This document is a product of the Session Initiation Protocol and the
Session Initiation Proposal Investigation Working Groups of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3326.txt"
}

@TECHREPORT{rfc3327,
AUTHOR="D. Willis and B. Hoeneisen",
TITLE="Session Initiation Protocol {(SIP)} Extension Header Field for Registering
{Non-Adjacent} Contacts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3327,
PAGES=17,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT={The REGISTER function is used in a Session Initiation Protocol
(SIP) system primarily to associate a temporary contact address with an
address-of-record. This contact is generally in the form of a Uniform
Resource Identifier (URI), such as Contact: <sip:alice(at)pc33.atlanta.com>
and is generally dynamic and associated with the IP address or hostname
of the SIP User Agent (UA). The problem is that network topology may
have one or more SIP proxies between the UA and the registrar, such that
any request traveling from the user's home network to the registered UA
must traverse these proxies. The REGISTER method does not give us a
mechanism to discover and record this sequence of proxies in the
registrar for future use. This document defines an extension header
field, {"}Path{"} which provides such a mechanism. This document is a
product of the Session Initiation Protocol and the Session Initiation
Proposal Investigation Working Groups of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3327.txt"
}

@TECHREPORT{rfc3330,
AUTHOR="Carla-Fabiana Chiasserini",
TITLE="{Special-Use} {IPv4} Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3330,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document describes the global and other specialized IPv4
address blocks that have been assigned by the Internet Assigned Numbers
Authority (IANA). It does not address IPv4 address space assigned to
operators and users through the Regional Internet Registries. It also
does not address allocations or assignments of IPv6 addresses or
autonomous system numbers.",
URL="http://www.rfc-editor.org/rfc/rfc3330.txt"
}

@TECHREPORT{rfc3331,
AUTHOR="K. Morneault and R. Dantu and G. Sidebottom and B. Bidulock and J. Heitz",
TITLE="Signaling System 7 {(SS7)} Message Transfer Part 2 {(MTP2)} - User
Adaptation Layer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3331,
PAGES=94,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document defines a protocol for the backhauling of
Signaling System 7 Message Transfer Part 2 (SS7 MTP2) User signalling
messages over IP using the Stream Control Transmission Protocol (SCTP).
This protocol would be used between a Signalling Gateway (SG) and Media
Gateway Controller (MGC). It is assumed that the SG receives SS7
signalling over a standard SS7 interface using the SS7 Message Transfer
Part (MTP) to provide transport. The Signalling Gateway would act as a
Signalling Link Terminal. This document is a product of the Signaling
Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3331.txt"
}

@TECHREPORT{rfc3332,
EDITOR="G. Sidebottom and K. Morneault and I. W. Ed.",
TITLE="Signaling System 7 {(SS7)} Message Transfer Part 3 {(MTP3)} - User
Adaptation Layer {(M3UA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3332,
PAGES=120,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This memo defines a protocol for supporting the transport of
any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP
using the services of the Stream Control Transmission Protocol. Also,
provision is made for protocol elements that enable a seamless operation
of the MTP3-User peers in the SS7 and IP domains. This protocol would be
used between a Signalling Gateway (SG) and a Media Gateway Controller
(MGC) or IP-resident Database, or between two IP-based applications. It
is assumed that the SG receives SS7 signalling over a standard SS7
interface using the SS7 Message Transfer Part (MTP) to provide
transport.",
URL="http://www.rfc-editor.org/rfc/rfc3332.txt"
}

@TECHREPORT{rfc3334,
AUTHOR="Tanja Zseby and S. Zander and C. Carle",
TITLE="{Policy-Based} Accounting",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3334,
PAGES=44,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT="This document describes policy-based accounting which is an
approach to provide flexibility to accounting architectures. Accounting
policies describe the configuration of an accounting architecture in a
standardized way. They are used to instrument the accounting
architecture and can be exchanged between Authentication, Authorization
and Accounting (AAA) entities in order to share configuration
information. This document describes building blocks and message
sequences for policy-based accounting in the generic AAA architecture
(RFC 2903). Examples are given for the usage of accounting policies in
different scenarios. It is also shown how accounting components can be
integrated into the AAA authorization framework (RFC 2904). This
document does not propose a language for the description of accounting
policies. Rather, it is assumed that a suitable policy language can be
chosen from existing or upcoming standards.",
URL="http://www.rfc-editor.org/rfc/rfc3334.txt"
}

@TECHREPORT{rfc3335,
AUTHOR="T. Harding and R. Drummond and C. Jimmy Shih",
TITLE="{MIME-based} Secure {Peer-to-Peer} Business Data Interchange over the
Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3335,
PAGES=29,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document describes how to exchange structured business
data securely using SMTP transport for Electronic Data Interchange, (EDI
- either the American Standards Committee X12 or UN/EDIFACT, Electronic
Data Interchange for Administration, Commerce and Transport), XML or
other data used for business to business data interchange. The data is
packaged using standard MIME content-types. Authentication and privacy
are obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP
security body parts. Authenticated acknowledgements make use of
multipart/signed replies to the original SMTP message.",
URL="http://www.rfc-editor.org/rfc/rfc3335.txt"
}

@TECHREPORT{rfc3336,
AUTHOR="B. Thompson and T. Koren and B. Buffam",
TITLE="{PPP} Over Asynchronous Transfer Mode Adaptation Layer 2 {(AAL2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3336,
PAGES=16,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="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 ATM Adaptation Layer 2 (AAL2) for
framing PPP encapsulated packets. This document is a product of the
Point-to-Point Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3336.txt"
}

@TECHREPORT{rfc3337,
AUTHOR="B. Thompson and T. Koren and B. Buffam",
TITLE="Class Extensions for {PPP} over Asynchronous Transfer Mode Adaptation Layer
2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3337,
PAGES=7,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="The Point-to-Point Protocol (PPP) over Asynchronous Transfer
Mode (ATM) Adaptation Layer 2 defines the encapsulation that allows a
PPP session to be transported over an ATM virtual circuit using the ATM
Adaptation Layer 2 (AAL2) adaptation layer. This document defines a set
of class extensions to PPP over AAL2 that implement equivalent
functionality to Multi Class Multi Link PPP over a single ATM virtual
circuit. Instead of using Multi Link PPP as the basis for fragmentation
functionality, this document uses the functionality of the Segmentation
and Reassembly Service Specific Convergence Sublayer that is already
required as the basic encapsulation format of PPP over AAL2. This
document is a product of the Point-to-Point Protocol Extensions Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3337.txt"
}

@TECHREPORT{rfc3338,
AUTHOR="S. Lee and M-k. Shin and Y-j. Kim and E. Nordmark and A. Durand",
TITLE={Dual Stack Hosts Using {{"}Bump-in-the-API{"}} {(BIA)}},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3338,
PAGES=17,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT={This document specifies a mechanism of dual stack hosts using
a technique called {"}Bump-in-the-API{"}(BIA) which allows for the hosts to
communicate with other IPv6 hosts using existing IPv4 applications. The
goal of this mechanism is the same as that of the Bump-in-the-stack
mechanism, but this mechanism provides the translation method between
the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without
IP header translation. This document is a product of the Next Generation
Transition Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3338.txt"
}

@TECHREPORT{rfc3339,
AUTHOR="G. Klyne and C. Newman",
TITLE="Date and Time on the Internet: Timestamps",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3339,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT="This document defines a date and time format for use in
Internet protocols that is a profile of the ISO 8601 standard for
representation of dates and times using the Gregorian calendar. This
document is a product of the Instant Messaging and Presence Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3339.txt"
}

@TECHREPORT{rfc3340,
AUTHOR="M. P. Rose and G. Klyne and D. H. Crocker",
TITLE="The Application Exchange Core",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3340,
PAGES=40,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT="This memo describes Application Exchange (APEX) Core, an
extensible, asynchronous message relaying service for application layer
programs. This document is a product of the Application Exchange Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3340.txt"
}

@TECHREPORT{rfc3341,
AUTHOR="M. P. Rose and G. Klyne and D. H. Crocker",
TITLE="The Application Exchange {(APEX)} Access Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3341,
PAGES=26,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT={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. This document is a product of the Application
Exchange Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3341.txt"
}

@TECHREPORT{rfc3342,
AUTHOR="E. Dixon and H. Franklin and J. Kint and G. Klyne and D. New and S. Pead
and M. P. Rose and M. Schwartz",
TITLE="The Application Exchange {(APEX)} Option Party Pack, Part Deux!",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3342,
PAGES=22,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT={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{"}. This
document is a product of the Application Exchange Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3342.txt"
}

@TECHREPORT{rfc3344,
AUTHOR="Charles E. Perkins",
TITLE="{IP} Mobility Support for {IPv4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3344,
MONTH=aug,
YEAR=2002,
KEYWORDS="Mobile IP, Mobility",
ABSTRACT="This document specifies protocol enhancements that allow transparent
   routing of IP datagrams to mobile nodes in the Internet.  Each mobile
   node is always identified by its home address, regardless of its
   current point of attachment to the Internet.  While situated away
   from its home, a mobile node is also associated with a care-of
   address, which provides information about its current point of
   attachment to the Internet.  The protocol provides for registering
   the care-of address with a home agent.  The home agent sends
   datagrams destined for the mobile node through a tunnel to the care-
   of address.  After arriving at the end of the tunnel, each datagram
   is then delivered to the mobile node.",
URL="http://www.ietf.org/rfc/rfc3344.txt"
}

@TECHREPORT{rfc3345,
AUTHOR="D. McPherson and V. Gill and D. Walton and A. Retana",
TITLE="Border Gateway Protocol {(BGP)} Persistent Route Oscillation Condition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3345,
PAGES=19,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT={In particular configurations, the BGP scaling mechanisms
defined in {"}BGP Route Reflection - An Alternative to Full Mesh IBGP{"}
and
{"}Autonomous System Confederations for BGP{"} will introduce persistent
BGP
route oscillation. This document discusses the two types of persistent
route oscillation that have been identified, describes when these
conditions will occur, and provides some network design guidelines to
avoid introducing such occurrences. This document is a product of the
Inter-Domain Routing Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3345.txt"
}

@TECHREPORT{rfc3346,
AUTHOR="J. Boyle and V. Gill and A. Hannan and D. B. Cooper and Daniel O. Awduche
and B. Christian and W. S. Lai",
TITLE="Applicability Statement for Traffic Engineering with {MPLS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3346,
PAGES=14,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document describes the applicability of Multiprotocol
Label Switching (MPLS) to traffic engineering in IP networks. Special
considerations for deployment of MPLS for traffic engineering in
operational contexts are discussed and the limitations of the MPLS
approach to traffic engineering are highlighted. This document is a
product of the Internet Traffic Engineering Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3346.txt"
}

@TECHREPORT{rfc3347,
AUTHOR="M. Krueger and R. Haagens",
TITLE="Small Computer Systems Interface protocol over the Internet {(iSCSI)}
Requirements and Design Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3347,
PAGES=26,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT="This document specifies the requirements iSCSI and its related
infrastructure should satisfy and the design considerations guiding the
iSCSI protocol development efforts. In the interest of timely adoption
of the iSCSI protocol, the IPS group has chosen to focus the first
version of the protocol to work with the existing SCSI architecture and
commands, and the existing TCP/IP transport layer. Both these protocols
are widely-deployed and well-understood. The thought is that using these
mature protocols will entail a minimum of new invention, the most rapid
possible adoption, and the greatest compatibility with Internet
architecture, protocols, and equipment.",
URL="http://www.rfc-editor.org/rfc/rfc3347.txt"
}

@TECHREPORT{rfc3348,
AUTHOR="M. Gahrns and R. Cheng",
TITLE="The Internet Message Action Protocol {(IMAP4)} Child Mailbox Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3348,
PAGES=6,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT={The Internet Message Action Protocol (IMAP4) CHILDREN
extension provides a mechanism for a client to efficiently determine if
a particular mailbox has children, without issuing a LIST {"}{"} * or a
LIST
{"}{"} \% for each mailbox.},
URL="http://www.rfc-editor.org/rfc/rfc3348.txt"
}

@TECHREPORT{rfc3349,
AUTHOR="M. P. Rose",
TITLE="A Transient Prefix for Identifying Profiles under Development by the
Working Groups of the Internet Engineering Task Force",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3349,
PAGES=6,
DAYS=15,
MONTH=jul,
YEAR=2002,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc3349.txt"
}

@TECHREPORT{rfc3351,
AUTHOR="N. Charlton and M. Gasson and G. Gybels and M. Spanner and A. van Wijk",
TITLE="User Requirements for the Session Initiation Protocol {(SIP)} in Support of
Deaf, Hard of Hearing and Speech-impaired Individuals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3351,
PAGES=17,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document presents a set of Session Initiation Protocol
(SIP) user requirements that support communications for deaf, hard of
hearing and speech-impaired individuals. These user requirements address
the current difficulties of deaf, hard of hearing and speech-impaired
individuals in using communications facilities, while acknowledging the
multi-functional potential of SIP-based communications. A number of
issues related to these user requirements are further raised in this
document. Also included are some real world scenarios and some technical
requirements to show the robustness of these requirements on a
concept-level. This document is a product of the Session Initiation
Proposal Investigation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3351.txt"
}

@TECHREPORT{rfc3353,
AUTHOR="D. Ooms and B. Sales and W. Livens and A. Acharya and F. Griffoul and F.
Ansari",
TITLE="Overview of {IP} Multicast in a {Multi-Protocol} Label Switching {(MPLS)}
Environment",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3353,
PAGES=30,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document offers a framework for IP multicast deployment
in an MPLS environment. Issues arising when MPLS techniques are applied
to IP multicast are overviewed. The pros and cons of existing IP
multicast routing protocols in the context of MPLS are described and the
relation to the different trigger methods and label distribution modes
are discussed. The consequences of various layer 2 (L2) technologies are
listed. Both point-to-point and multi-access networks are considered.
This document is a product of the Multiprotocol Label Switching Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3353.txt"
}

@TECHREPORT{rfc3354,
AUTHOR="D. Eastlake 3rd",
TITLE="Internet Open Trading Protocol Version 2 Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3354,
PAGES=6,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document gives requirements for the Internet Open Trading
Protocol (IOTP) Version 2 by describing design principles and scope and
dividing features into those which will, may, or will not be included.
Version 2 of the IOTP will extend the interoperable framework for
Internet commerce capabilities of Version 1 while replacing the XML
messaging and digital signature part of IOTP v1 with standards based
mechanisms. This document is a product of the Open Trading Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3354.txt"
}

@TECHREPORT{rfc3355,
AUTHOR="A. Singh and R. Turner and R. Tio and S. Nanji",
TITLE="Layer Two Tunnelling Protocol {(L2TP)} Over {ATM} Adaptation Layer 5
{(AAL5)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3355,
PAGES=13,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="The Layer Two Tunneling Protocol (L2TP) provides a standard
method for transporting the link layer of the Point-to-Point Protocol
(PPP) between a dial-up server and a Network Access Server, using a
network connection in lieu of a physical point-to-point connection. This
document describes the use of an Asynchronous Transfer Mode (ATM)
network for the underlying network connection. ATM User-Network
Interface (UNI) Signaling Specification Version 4.0 or Version 3.1 with
ATM Adaptation Layer 5 (AAL5) are supported as interfaces to the ATM
network. This document is a product of the Layer Two Tunneling Protocol
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3355.txt"
}

@TECHREPORT{rfc3356,
AUTHOR="G. S. Fishman and S. Bradner",
TITLE="Internet Engineering Task Force and International Telecommunication Union -
Telecommunications Standardization Sector Collaboration Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3356,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document provides guidance to aid in the understanding of
collaboration on standards development between the International
Telecommunication Union -- Telecommunication Standardization Sector
(ITU-T) and the Internet Society (ISOC) / Internet Engineering Task
Force (IETF). It is an update of and obsoletes RFC 2436. The updates
reflect changes in the IETF and ITU-T since RFC 2436 was written. The
bulk of this document is common text with ITU-T Supplement 3 to the
ITU-T A-Series Recommendations. Note: This was approved by ITU-T TSAG on
30 November 2001 as a Supplement to the ITU-T A-Series of
Recommendations (will be numbered as A-Series Supplement 3).",
URL="http://www.rfc-editor.org/rfc/rfc3356.txt"
}

@TECHREPORT{rfc3357,
AUTHOR="R. Koodli and R. Ravikanth",
TITLE="One-way Loss Pattern Sample Metrics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3357,
PAGES=15,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT={Using the base loss metric defined in RFC 2680, this document
defines two derived metrics {"}loss distance{"} and {"}loss period{"}, and
the
associated statistics that together capture loss patterns experienced by
packet streams on the Internet. The Internet exhibits certain specific
types of behavior (e.g., bursty packet loss) that can affect the
performance seen by the users as well as the operators. The loss pattern
or loss distribution is a key parameter that determines the performance
observed by the users for certain real-time applications such as packet
voice and video. For the same loss rate, two different loss
distributions could potentially produce widely different perceptions of
performance. This document is a product of the IP Performance Metrics
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3357.txt"
}

@TECHREPORT{rfc3358,
AUTHOR="R. Koodli and R. Ravikanth",
TITLE="Optional Checksums in Intermediate System to Intermediate System {(ISIS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3358,
PAGES=4,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document describes an optional extension to the
Intermediate System to Intermediate System (ISIS) protocol, used today
by several Internet Service Proviers (ISPs) for routing within their
clouds. ISIS is an interior gateway routing protocol developed
originally by OSI and used with IP extensions as Interior Gateway
Protocol (IGP). ISIS originally does not provide Complete Sequence
Numbers Protocol Data (CSNP) and Partial Sequence Numbers Protocol Data
Unit (PSNP) checksums, relying on the underlying layers to verify the
integrity of information provided. Experience with the protocol shows
that this precondition does not always hold and scenarios can be
imagined that impact protocol functionality. This document introduces a
new optional Type, Length and Value (TLV) providing checksums. This
document is a product of the IS-IS for IP Internets Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3358.txt"
}

@TECHREPORT{rfc3359,
AUTHOR="T. Przygienda",
TITLE="Reserved Type, Length and Value {(TLV)} Codepoints in Intermediate System
to Intermediate System",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3359,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document describes implementation codepoints within
Intermediate System to Intermediate System (IS-IS) used today by several
ISPs for routing within their clouds. IS-IS is an interior gateway
routing protocol developed originally by OSI and used with IP extensions
as Interior Gateway Protocol (IGP). This document summarizes all Table,
Length and Value (TLV) codepoints that are being used by the protocol
and its pending extensions. This document is a product of the IS-IS for
IP Internets Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3359.txt"
}

@TECHREPORT{rfc3360,
AUTHOR="S. Floyd",
TITLE="Inappropriate {TCP} Resets Considered Harmful",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3360,
PAGES=19,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document is being written because there are a number of
firewalls in the Internet that inappropriately reset a TCP connection
upon receiving certain TCP SYN packets, in particular, packets with
flags set in the Reserved field of the TCP header. In this document we
argue that this practice is not conformant with TCP standards, and is an
inappropriate overloading of the semantics of the TCP reset. We also
consider the longer-term consequences of this and similar actions as
obstacles to the evolution of the Internet infrastructure.",
URL="http://www.rfc-editor.org/rfc/rfc3360.txt"
}

@TECHREPORT{rfc3361,
AUTHOR="Henning Schulzrinne",
TITLE="Dynamic Host Configuration Protocol {(DHCP-for-IPv4)} Option for Session
Initiation Protocol {(SIP)} Servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3361,
PAGES=7,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document defines a Dynamic Host Configuration Protocol
(DHCP-for-IPv4) option that contains a list of domain names or IPv4
addresses that can be mapped to one or more Session Initiation Protocol
(SIP) outbound proxy servers. This is one of the many methods that a SIP
client can use to obtain the addresses of such a local SIP server. This
document is a product of the Session Initiation Protocol Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3361.txt"
}

@TECHREPORT{rfc3362,
AUTHOR="G. Parsons",
TITLE="Real-time Facsimile {(T.38)} - image/t38 {MIME} Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3362,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document describes the registration of the MIME sub-type
image/t38. The encoding is defined by ITU Recommendation T.38 and is
intended for use as an Session Description Protocol (SDP) media
descriptor.",
URL="http://www.rfc-editor.org/rfc/rfc3362.txt"
}

@TECHREPORT{rfc3363,
AUTHOR="R. Bush and A. Durand and B. Fink and O. Gudmundsson and T. Hain",
TITLE="Representing Internet Protocol version 6 {(IPv6)} Addresses in the Domain
Name System {(DNS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3363,
PAGES=6,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document clarifies and updates the standards status of
RFCs that define direct and reverse map of IPv6 addresses in DNS. This
document moves the A6 and Bit label specifications to experimental
status. This document is a product of the DNS Extensions Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3363.txt"
}

@TECHREPORT{rfc3364,
AUTHOR="R. Austein",
TITLE="Tradeoffs in Domain Name System {(DNS)} Support for Internet Protocol
version 6 {(IPv6)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3364,
PAGES=11,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="The IETF has two different proposals on the table for how to
do DNS support for IPv6, and has thus far failed to reach a clear
consensus on which approach is better. This note attempts to examine the
pros and cons of each approach, in the hope of clarifying the debate so
that we can reach closure and move on. This document is a product of the
DNS Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3364.txt"
}

@TECHREPORT{rfc3365,
AUTHOR="J. Schiller",
TITLE="Strong Security Requirements for Internet Engineering Task Force Standard
Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3365,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="It is the consensus of the IETF that IETF standard protocols
MUST make use of appropriate strong security mechanisms. This document
describes the history and rationale for this doctrine and establishes
this doctrine as a best current practice.",
URL="http://www.rfc-editor.org/rfc/rfc3365.txt"
}

@TECHREPORT{rfc3366,
AUTHOR="G. Fairhurst and L. H. Wood",
TITLE="Advice to link designers on link Automatic Repeat reQuest {(ARQ)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3366,
PAGES=27,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document provides advice to the designers of digital
communication equipment and link-layer protocols employing link-layer
Automatic Repeat reQuest (ARQ) techniques. This document presumes that
the designers wish to support Internet protocols, but may be unfamiliar
with the architecture of the Internet and with the implications of their
design choices for the performance and efficiency of Internet traffic
carried over their links. ARQ is described in a general way that
includes its use over a wide range of underlying physical media,
including cellular wireless, wireless LANs, RF links, and other types of
channel. This document also describes issues relevant to supporting IP
traffic over physical-layer channels where performance varies, and where
link ARQ is likely to be used.",
URL="http://www.rfc-editor.org/rfc/rfc3366.txt"
}

@TECHREPORT{rfc3367,
AUTHOR="N. Popp and M. Mealling and M. Moseley",
TITLE="Common Name Resolution Protocol {(CNRP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3367,
PAGES=42,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT={People often refer to things in the real world by a common
name or phrase, e.g., a trade name, company name, or a book title. These
names are sometimes easier for people to remember and type than URLs.
Furthermore, because of the limited syntax of URLs, companies and
individuals are finding that the ones that might be most reasonable for
their resources are being used elsewhere and so are unavailable. For the
purposes of this document, a {"}common name{"} is a word or a phrase,
without imposed syntactic structure, that may be associated with a
resource. This effort is about the creation of a protocol for client
applications to communicate with common name resolution services, as
exemplified in both the browser enhancement and search site paradigms.
Although the protocol's primary function is resolution, it is also
intended to address issues of internationalization and localization.
Name resolution services are not generic search services and thus do not
need to provide complex Boolean query, relevance ranking or similar
capabilities. The protocol is a simple, minimal interoperable core.
Mechanisms for extension are provided, so that additional capabilities
can be added. This document is a product of the Common Name Resolution
Protocol Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3367.txt"
}

@TECHREPORT{rfc3368,
AUTHOR="M. Mealling",
TITLE="The 'go' {URI} Scheme for the Common Name Resolution Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3368,
PAGES=8,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT={This document defines a URI scheme, 'go:' to be used with the
Common Name Resolution Protocol. Specifically it lays out the syntactic
components and how those components are used by URI Resolution to find
the available transports for a CNRP service. Care should be taken with
several of the URI components because, while they may look like
components found in other URI schemes, they often do not act like them.
The {"}go{"} scheme has more in common with the location independent
{"}news{"}
scheme than any other URI scheme. This document is a product of the
Common Name Resolution Protocol Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3368.txt"
}

@TECHREPORT{rfc3369,
AUTHOR="R. Housley",
TITLE="Cryptographic Message Syntax {(CMS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3369,
PAGES=52,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document describes the Cryptographic Message Syntax
(CMS). This syntax is used to digitally sign, digest, authenticate, or
encrypt arbitrary message content. This document is a product of the
S/MIME Mail Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3369.txt"
}

@TECHREPORT{rfc3370,
AUTHOR="R. Housley",
TITLE="Cryptographic Message Syntax {(CMS)} Algorithms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3370,
PAGES=24,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This document describes the conventions for using several
cryptographic algorithms with the Cryptographic Message Syntax (CMS).
The CMS is used to digitally sign, digest, authenticate, or encrypt
arbitrary message contents. This document is a product of the S/MIME
Mail Security Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3370.txt"
}

@TECHREPORT{rfc3371,
AUTHOR="E. Caves and P. Calhoun and R. M. Wheeler",
TITLE={Layer Two Tunneling Protocol {{"}L2TP{"}} Management Information Base},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3371,
PAGES=70,
DAYS=15,
MONTH=aug,
YEAR=2002,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing networks using
Layer 2 Tunneling Protocol (L2TP). This document is a product of the
Layer Two Tunneling Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3371.txt"
}

@TECHREPORT{rfc3372,
AUTHOR="A. Vemuri and J. Peterson",
TITLE="Session Initiation Protocol for Telephones {(SIP-T):} {(SIP-T):} Context
and Architectures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3372,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="The popularity of gateways that interwork between the PSTN
(Public Switched Telephone Network) and SIP networks has motivated the
publication of a set of common practices that can assure consistent
behavior across implementations. This document taxonomizes the uses of
PSTN-SIP gateways, provides uses cases, and identifies mechanisms
necessary for interworking. The mechanisms detail how SIP provides for
both 'encapsulation' (bridging the PSTN signaling across a SIP network)
and 'translation' (gatewaying).",
URL="http://www.rfc-editor.org/rfc/rfc3372.txt"
}

@TECHREPORT{rfc3373,
AUTHOR="D. Katz and R. Saluja",
TITLE="{Three-Way} Handshake for Intermediate System to Intermediate System
{(IS-IS)} {Point-to-Point} Adjacencies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3373,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="The IS-IS routing protocol (ISO 10589) requires reliable
protocols at the link layer for point-to-point links. As a result, it
does not use a three-way handshake when establishing adjacencies on
point-to-point media. This paper defines a backward-compatible extension
to the protocol that provides for a three-way handshake. It is fully
interoperable with systems that do not support the extension.
Additionally, the extension allows the robust operation of more than 256
point-to-point links on a single router. This extension has been
implemented by multiple router vendors; this paper is provided as
information to the Internet community in order to allow interoperable
implementations to be built by other vendors. This document is a product
of the IS-IS for IP Internets Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3373.txt"
}

@TECHREPORT{rfc3374,
EDITOR="J. Kempf",
TITLE="Problem Description: Reasons For Performing Context Transfers Between Nodes
in an {IP} Access Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3374,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT={In IP access networks that support host mobility, the routing
paths between the host and the network may change frequently and
rapidly. In some cases, the host may establish certain context transfer
candidate services on subnets that are left behind when the host moves.
Examples of such services are Authentication, Authorization, and
Accounting (AAA), header compression, and Quality of Service (QoS). In
order for the host to obtain those services on the new subnet, the host
must explicitly re-establish the service by performing the necessary
signaling flows from scratch. In some cases, this process would
considerably slow the process of establishing the mobile host on the new
subnet. An alternative is to transfer information on the existing state
associated with these services, or context, to the new subnet, a process
called {"}context transfer{"}. This document discusses the desirability of
context transfer for facilitating seamless IP mobility.},
URL="http://www.rfc-editor.org/rfc/rfc3374.txt"
}

@TECHREPORT{rfc3375,
AUTHOR="S. Hollenbeck",
TITLE="Generic {Registry-Registrar} Protocol Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3375,
PAGES=21,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document describes high-level functional and interface
requirements for a client-server protocol for the registration and
management of Internet domain names in shared registries. Specific
technical requirements detailed for protocol design are not presented
here. Instead, this document focuses on the basic functions and
interfaces required of a protocol to support multiple registry and
registrar operational models.",
URL="http://www.rfc-editor.org/rfc/rfc3375.txt"
}

@TECHREPORT{rfc3376,
AUTHOR="B. Cain and S. E. Deering and I. Kouvelas and B. Fenner and A. Thyagarajan",
TITLE="Internet Group Management Protocol, Version 3",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3376,
PAGES=53,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT={This document specifies Version 3 of the Internet Group
Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems
to report their IP multicast group memberships to neighboring multicast
routers. Version 3 of IGMP adds support for {"}source filtering{"}, that
is,
the ability for a system to report interest in receiving packets *only*
from specific source addresses, or from *all but* specific source
addresses, sent to a particular multicast address. That information may
be used by multicast routing protocols to avoid delivering multicast
packets from specific sources to networks where there are no interested
receivers. This document obsoletes RFC 2236. This document is a product
of the Inter-Domain Multicast Routing Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3376.txt"
}

@TECHREPORT{rfc3377,
AUTHOR="J. L. Hodges and R. Morgan",
TITLE="Lightweight Directory Access Protocol (v3): Technical Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3377,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT={This document specifies the set of RFCs comprising the
Lightweight Directory Access Protocol Version 3 (LDAPv3), and addresses
the {"}IESG Note{"} attached to RFCs 2251 through 2256.},
URL="http://www.rfc-editor.org/rfc/rfc3377.txt"
}

@TECHREPORT{rfc3378,
AUTHOR="R. Housley and S. Hollenbeck",
TITLE="{EtherIP:} Tunneling Ethernet Frames in {IP} Datagrams",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3378,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document describes the EtherIP, an early tunneling
protocol, to provide informational and historical context for the
assignment of IP protocol 97. EtherIP tunnels Ethernet and IEEE 802.3
media access control frames in IP datagrams so that non-IP traffic can
traverse an IP internet. The protocol is very lightweight, and it does
not provide protection against infinite loops.",
URL="http://www.rfc-editor.org/rfc/rfc3378.txt"
}

@TECHREPORT{rfc3379,
AUTHOR="D. Pinkas and R. Housley",
TITLE="Delegated Path Validation and Delegated Path Discovery Protocol
Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3379,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document specifies the requirements for Delegated Path
Validation (DPV) and Delegated Path Discovery (DPD) for Public Key
Certificates. It also specifies the requirements for DPV and DPD policy
management. This document is a product of the Public-Key Infrastructure
(X.509) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3379.txt"
}

@TECHREPORT{rfc3380,
AUTHOR="T. Hastings and R. Herriot and C. Kugler and H. Lewis",
TITLE="Internet Printing Protocol {(IPP):} Job and Printer Set Operations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3380,
PAGES=59,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT={This document is an OPTIONAL extension to the Internet
Printing Protocol (IPP/1.0 and IPP/1.1). This document specifies 3
additional OPTIONAL operations for use with the Internet Printing
Protocol/1.0 (IPP) and IPP/1.1. The end user, operator, and
administrator Set-Job-Attributes and Set-Printer-Attributes operations
are used to modify IPP Job objects and Printer objects, respectively.
The Get-Printer-Supported-Values administrative operation returns values
that the IPP Printer will accept for setting its {"}xxx-supported{"}
attributes. This document is a product of the Internet Printing Protocol
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3380.txt"
}

@TECHREPORT{rfc3381,
AUTHOR="T. Hastings and H. Lewis and R. Bergman",
TITLE="Internet Printing Protocol {(IPP):} Job Progress Attributes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3381,
PAGES=17,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT={This document defines four new Job Description attributes for
monitoring job progress to be registered as OPTIONAL extensions to the
Internet Printing Protocol (IPP/1.0 and IPP/1.1). These attributes are
drawn from the PWG Job Monitoring MIB. This document also defines a new
{"}sheet-collate{"} Job Template attribute to control sheet collation and
to
help with the interpretation of the job progress attributes. This
document is a product of the Internet Printing Protocol Working Group of
the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3381.txt"
}

@TECHREPORT{rfc3382,
AUTHOR="R. deBry and T. Hastings and R. Herriot and K. Ocke and P. Zehler",
TITLE="Internet Printing Protocol {(IPP):} The 'collection' attribute syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3382,
PAGES=38,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT={This document specifies an OPTIONAL attribute syntax called
'collection' for use with the Internet Printing Protocol (IPP/1.0 and
IPP/1.1). A 'collection' is a container holding one or more named
values, which are called {"}member{"} attributes. A collection allows data
to be grouped like a PostScript dictionary or a Java Map. This document
also specifies the conformance requirements for a definition document
that defines a collection attribute. Finally, this document gives some
illustrative example collection attribute definitions that are not
intended as actual attribute specifications. This document is a product
of the Internet Printing Protocol Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3382.txt"
}

@TECHREPORT{rfc3383,
AUTHOR="K. Zeilenga",
TITLE="Internet Assigned Numbers Authority {(IANA)} Considerations for the
Lightweight Directory Access Protocol {(LDAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3383,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document provides procedures for registering extensible
elements of the Lightweight Directory Access Protocol (LDAP). This
document also provides guidelines to the Internet Assigned Numbers
Authority (IANA) describing conditions under which new values can be
assigned. This document is a product of the LDAP (v3) Revision Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3383.txt"
}

@TECHREPORT{rfc3384,
AUTHOR="E. Stokes and R. Weiser and R. Moats and R. Huber",
TITLE="Lightweight Directory Access Protocol (version {3)} Replication
Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3384,
PAGES=31,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT="This document discusses the fundamental requirements for
replication of data accessible via the Lightweight Directory Access
Protocol (version 3) (LDAPv3). It is intended to be a gathering place
for general replication requirements needed to provide interoperability
between informational directories. This document is a product of the
LDAP Duplication/Replication/Update Protocols Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3384.txt"
}

@TECHREPORT{rfc3385,
AUTHOR="D. Sheinwald and J. Satran and P. Thaler and V. Cavanna",
TITLE="Internet Protocol Small Computer System Interface {(iSCSI)} Cyclic
Redundancy Check {(CRC)/Checksum} Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3385,
PAGES=23,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="In this memo, we attempt to give some estimates for the
probability of undetected errors to facilitate the selection of an error
detection code for the Internet Protocol Small Computer System Interface
(iSCSI). We will also attempt to compare Cyclic Redundancy Checks (CRCs)
with other checksum forms (e.g., Fletcher, Adler, weighted checksums),
as permitted by available data.",
URL="http://www.rfc-editor.org/rfc/rfc3385.txt"
}

@TECHREPORT{rfc3386,
EDITOR="W. S. Lai and D. McDysan+",
TITLE="Network Hierarchy and Multilayer Survivability",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3386,
PAGES=27,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document presents a proposal of the near-term and
practical requirements for network survivability and hierarchy in
current service provider environments. This document is a product of the
Internet Traffic Engineering Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3386.txt"
}

@TECHREPORT{rfc3387,
AUTHOR="M. Eder and H. Chaskar and S. Nag",
TITLE="Considerations from the Service Management Research Group {(SMRG)} on
Quality of Service {(QoS)} in the {IP} Network",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3387,
PAGES=19,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="The guiding principles in the design of IP network management
were simplicity and no centralized control. The best effort service
paradigm was a result of the original management principles and the
other way around. New methods to distinguish the service given to one
set of packets or flows relative to another are well underway. However,
as IP networks evolve the management approach of the past may not apply
to the Quality of Service (QoS)-capable network envisioned by some for
the future. This document examines some of the areas of impact that QoS
is likely to have on management and look at some questions that remain
to be addressed.",
URL="http://www.rfc-editor.org/rfc/rfc3387.txt"
}

@TECHREPORT{rfc3388,
AUTHOR="G. Camarillo and G. Eriksson and J. Holler and Henning Schulzrinne",
TITLE="Grouping of Media Lines in the Session Description Protocol {(SDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3388,
PAGES=21,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT={This document defines two Session Description Protocol (SDP)
attributes: {"}group{"} and {"}mid{"}. They allow to group together several
{"}m{"}
lines for two different purposes: for lip synchronization and for
receiving media from a single flow (several media streams) that are
encoded in different formats during a particular session, on different
ports and host interfaces. This document is a product of the Multiparty
Multimedia Session Control Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3388.txt"
}

@TECHREPORT{rfc3389,
AUTHOR="R. Zopf",
TITLE="Real-time Transport Protocol {(RTP)} Payload for Comfort Noise {(CN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3389,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This document describes a Real-time Transport Protocol (RTP)
payload format for transporting comfort noise (CN). The CN payload type
is primarily for use with audio codecs that do not support comfort noise
as part of the codec itself such as ITU-T Recommendations G.711, G.726,
G.727, G.728, and G.722. This document is a product of the Audio/Video
Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3389.txt"
}

@TECHREPORT{rfc3390,
AUTHOR="M. Allman and S. Floyd and C. Partridge",
TITLE="Increasing {TCP's} Initial Window",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3390,
PAGES=15,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT="This document specifies an optional standard for TCP to
increase the permitted initial window from one or two segment(s) to
roughly 4K bytes, replacing RFC 2414. It discusses the advantages and
disadvantages of the higher initial window, and includes discussion of
experiments and simulations showing that the higher initial window does
not lead to congestion collapse. Finally, this document provides
guidance on implementation issues. This document is a product of the
Transport Area Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3390.txt"
}

@TECHREPORT{rfc3391,
AUTHOR="R. Herriot",
TITLE="The {MIME} {Application/Vnd.pwg-multiplexed} {Content-Type}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3391,
PAGES=25,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="The Application/Vnd.pwg-multiplexed content-type, like the
Multipart/Related content-type, provides a mechanism for representing
objects that consist of multiple components. An
Application/Vnd.pwg-multiplexed entity contains a sequence of chunks.
Each chunk contains a MIME message or a part of a MIME message. Each
MIME message represents a component of the compound object, just as a
body part of a Multipart/Related entity represents a component. With a
Multipart/Related entity, a body part and its reference in some other
body part may be separated by many octets. With an
Application/Vnd.pwg-multiplexed entity, a message and its reference in
some other message can be made quite close by chunking the message
containing the reference. For example, if a long message contains
references to images and the producer does not know of the need for each
image until it generates the reference, then
Application/Vnd.pwg-multiplexed allows the consumer to process the
reference to the image and the image before it consumes the entire long
message. This ability is important in printing and scanning
applications. This document defines the Application/Vnd.pwg-multiplexed
content-type. It also provides examples of its use.",
URL="http://www.rfc-editor.org/rfc/rfc3391.txt"
}

@TECHREPORT{rfc3392,
AUTHOR="R. Chandra and J. Scudder",
TITLE="Capabilities Advertisement with {BGP-4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3392,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document defines a new Optional Parameter, called
Capabilities, that is expected to facilitate the introduction of new
capabilities in the Border Gateway Protocol (BGP) by providing graceful
capability advertisement without requiring that BGP peering be
terminated. This document is a product of the Inter-Domain Routing
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3392.txt"
}

@TECHREPORT{rfc3393,
AUTHOR="C. Demichelis and P. F. Chimento",
TITLE="{IP} Packet Delay Variation Metric for {IP} Performance Metrics {(IPPM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3393,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT={This document refers to a metric for variation in delay of
packets across Internet paths. The metric is based on the difference in
the One-Way-Delay of selected packets. This difference in delay is
called {"}IP Packet Delay Variation (ipdv){"}. The metric is valid for
measurements between two hosts both in the case that they have
synchronized clocks and in the case that they are not synchronized. We
discuss both in this document. This document is a product of the IP
Performance Metrics Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3393.txt"
}

@TECHREPORT{rfc3394,
AUTHOR="J. Schaad and R. Housley",
TITLE="Advanced Encryption Standard {(AES)} Key Wrap Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3394,
PAGES=41,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="The purpose of this document is to make the Advanced
Encryption Standard (AES) Key Wrap algorithm conveniently available to
the Internet community. The United States of America has adopted AES as
the new encryption standard. The AES Key Wrap algorithm will probably be
adopted by the USA for encryption of AES keys. The authors took most of
the text in this document from the draft AES Key Wrap posted by NIST.
This document is a product of the S/MIME Mail Security Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3394.txt"
}

@TECHREPORT{rfc3395,
AUTHOR="A. Bierman and C. Bucci and R. Dietz and A. Warth",
TITLE="Remote Network Monitoring {MIB} Protocol Identifier Reference Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3395,
PAGES=21,
DAYS=15,
MONTH=sep,
YEAR=2002,
ABSTRACT="This memo defines extensions to the Protocol Identifier
Reference document for the identification of application verb
information. It updates the Protocol Identifier Reference document but
does not obsolete any portion of that document. In particular, it
describes the algorithms required to identify protocol operations
(verbs) within the protocol encapsulations managed with MIBs such as the
Remote Network Monitoring MIB Version 2, RFC 2021. This document is a
product of the Remote Network Monitoring Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3395.txt"
}

@TECHREPORT{rfc3396,
AUTHOR="T. Lemon and S. Cheshire",
TITLE="Encoding Long Options in the Dynamic Host Configuration Protocol {(DHCPv4)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3396,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document specifies the processing rules for Dynamic Host
Configuration Protocol (DHCPv4) options that appear multiple times in
the same message. Multiple instances of the same option are generated
when an option exceeds 255 octets in size (the maximum size of a single
option) or when an option needs to be split apart in order to take
advantage of DHCP option overloading. When multiple instances of the
same option appear in the options, file and/or sname fields in a DHCP
packet, the contents of these options are concatenated together to form
a single option prior to processing. This document is a product of
Dynamic Host Configuration Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3396.txt"
}

@TECHREPORT{rfc3397,
AUTHOR="B. Aboba and S. Cheshire",
TITLE="Dynamic Host Configuration Protocol {(DHCP)} Domain Search Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3397,
PAGES=8,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document defines a new Dynamic Host Configuration
Protocol (DHCP) option which is passed from the DHCP Server to the DHCP
Client to specify the domain search list used when resolving hostnames
using DNS.",
URL="http://www.rfc-editor.org/rfc/rfc3397.txt"
}

@TECHREPORT{rfc3398,
AUTHOR="G. Camarillo and A. B. Roach and J. Peterson and L. Ong",
TITLE="Integrated Services Digital Network {(ISDN)} User Part {(ISUP)} to Session
Initiation Protocol {(SIP)} Mapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3398,
PAGES=68,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes a way to perform the mapping between
two signaling protocols: the Session Initiation Protocol (SIP) and the
Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling
System No. 7 (SS7). This mechanism might be implemented when using SIP
in an environment where part of the call involves interworking with the
Public Switched Telephone Network (PSTN). This document is a product of
the Session Initiation Proposal Investigation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3398.txt"
}

@TECHREPORT{rfc3401,
AUTHOR="M. Mealling",
TITLE="Dynamic Delegation Discovery System {(DDDS)} Part One: The Comprehensive
{DDDS}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3401,
PAGES=6,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT="This document specifies the exact documents that make up the
complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract
algorithm for applying dynamically retrieved string transformation rules
to an application-unique string. This document along with RFC 3402, RFC
3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC
2276. This document is a product of the Uniform Resource Names Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3401.txt"
}

@TECHREPORT{rfc3402,
AUTHOR="M. Mealling",
TITLE="Dynamic Delegation Discovery System {(DDDS)} Part Two: The Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3402,
PAGES=17,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT={This document describes the Dynamic Delegation Discovery
System (DDDS) algorithm for applying dynamically retrieved string
transformation rules to an application-unique string. Well-formed
transformation rules will reflect the delegation of management of
information associated with the string. This document is also part of a
series that is completely specified in {"}Dynamic Delegation Discovery
System (DDDS) Part One: The Comprehensive DDDS{"} (RFC 3401). It is very
important to note that it is impossible to read and understand any
document in this series without reading the others. This document is a
product of the Uniform Resource Names Working Group of the IETF. This is
now a Proposed Standard Protocol.},
URL="http://www.rfc-editor.org/rfc/rfc3402.txt"
}

@TECHREPORT{rfc3403,
AUTHOR="M. Mealling",
TITLE="Dynamic Delegation Discovery System {(DDDS)} Part Three: The Domain Name
System {(DNS)} Database",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3403,
PAGES=14,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT={This document describes a Dynamic Delegation Discovery System
(DDDS) Database using the Domain Name System (DNS) as a distributed
database of Rules. The Keys are domain-names and the Rules are encoded
using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since
this document obsoletes RFC 2915, it is the official specification for
the NAPTR DNS Resource Record. It is also part of a series that is
completely specified in {"}Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS{"} (RFC 3401). It is very important to note
that it is impossible to read and understand any document in this series
without reading the others. This document is a product of the Uniform
Resource Names Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3403.txt"
}

@TECHREPORT{rfc3404,
AUTHOR="M. Mealling",
TITLE="Dynamic Delegation Discovery System {(DDDS)} Part Four: The Uniform
Resource Identifiers {(URI)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3404,
PAGES=18,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT={This document describes a specification for taking Uniform
Resource Identifiers (URI) and locating an authoritative server for
information about that URI. The method used to locate that authoritative
server is the Dynamic Delegation Discovery System. This document is part
of a series that is specified in {"}Dynamic Delegation Discovery System
(DDDS) Part One: The Comprehensive DDDS{"} (RFC 3401). It is very
important to note that it is impossible to read and understand any
document in this series without reading the others. This document is a
product of the Uniform Resource Names Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3404.txt"
}

@TECHREPORT{rfc3405,
AUTHOR="M. Mealling",
TITLE="Dynamic Delegation Discovery System {(DDDS)} Part Five: {URI.ARPA}
Assignment Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3405,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT={This document is fifth in a series that is completely
specified in {"}Dynamic Delegation Discovery System (DDDS) Part One: The
Comprehensive DDDS{"} (RFC 3401). It is very important to note that it is
impossible to read and understand any document in this series without
reading the others. This document is a product of the Uniform Resource
Names Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3405.txt"
}

@TECHREPORT{rfc3406,
AUTHOR="L. Daigle and D. van Gulik and R. Iannella and P. Faltstrom",
TITLE="Uniform Resource Names {(URN)} Namespace Definition Mechanisms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3406,
PAGES=22,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT={This document lays out general definitions of and mechanisms
for establishing Uniform Resource Names (URN) {"}namespaces{"}. The URN WG
has defined a syntax for URNs in RFC 2141, as well as some proposed
mechanisms for their resolution and use in Internet applications in RFC
3401 and RFC 3405. 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
in RFC 2288. This document is a product of the Uniform Resource Names
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3406.txt"
}

@TECHREPORT{rfc3407,
AUTHOR="F. Andreasen",
TITLE="Session Description Protocol {(SDP)} Simple Capability Declaration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3407,
PAGES=10,
DAYS=15,
MONTH=oct,
YEAR=2002,
ABSTRACT="This document defines a set of Session Description Protocol
(SDP) attributes that enables SDP to provide a minimal and backwards
compatible capability declaration mechanism. Such capability
declarations can be used as input to a subsequent session negotiation,
which is done by means outside the scope of this document. This provides
a simple and limited solution to the general capability negotiation
problem being addressed by the next generation of SDP, also known as
SDPng.",
URL="http://www.rfc-editor.org/rfc/rfc3407.txt"
}

@TECHREPORT{rfc3408,
AUTHOR="Z. Liu and K. Le",
TITLE="Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended
{Link-Layer} Assisted {RObust} Header Compression {(ROHC)} Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3408,
PAGES=7,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document defines an additional mode of the link-layer
assisted RObust Header Compression (ROHC) profile, also known as the
zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header
compression exists in order to prevent the single-octet ROHC header from
pushing a packet voice stream into the next higher fixed packet size for
the radio. It is usable in certain widely deployed older air interfaces.
This document adds the zero-byte operation for ROHC Bidirectional
Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode)
and Bidirectional Optimistic (O-mode) modes of header compression in RFC
3242. This document is a product of the Robust Header Compression
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3408.txt"
}

@TECHREPORT{rfc3409,
AUTHOR="K. Svanbro",
TITLE="Lower Layer Guidelines for Robust {RTP/UDP/IP} Header Compression",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3409,
PAGES=11,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes lower layer guidelines for robust
header compression (ROHC) and the requirements ROHC puts on lower
layers. The purpose of this document is to support the incorporation of
robust header compression algorithms, as specified in the ROHC working
group, into different systems such as those specified by Third
Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European
Technical Standards Institute (ETSI), etc. This document covers only
lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers
as specified in [RFC3095]. Both general guidelines and guidelines
specific for cellular systems are discussed in this document. This
document is a product of the Robust Header Compression Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3409.txt"
}

@TECHREPORT{rfc3410,
AUTHOR="J. D. Case and R. Mundy and D. Partain and B. Stewart",
TITLE="Introduction and Applicability Statements for {Internet-Standard}
Management Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3410,
PAGES=27,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="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).
The architecture is designed to be modular to allow the evolution of the
Framework over time. The document explains why using SNMPv3 instead of
SNMPv1 or SNMPv2 is strongly recommended. The document also recommends
that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to
Historic status. This document obsoletes RFC 2570. This document is a
product of the SNMPv3 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3410.txt"
}

@TECHREPORT{rfc3411,
AUTHOR="D. Harrington and R. Presuhn and B. Wijnen",
TITLE="An Architecture for Describing Simple Network Management Protocol {(SNMP)}
Management Frameworks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3411,
PAGES=64,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes an architecture for describing Simple
Network Management Protocol (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. This document obsoletes RFC 2571.",
URL="http://www.rfc-editor.org/rfc/rfc3411.txt"
}

@TECHREPORT{rfc3412,
AUTHOR="J. D. Case and D. Harrington and R. Presuhn and B. Wijnen",
TITLE="Message Processing and Dispatching for the Simple Network Management
Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3412,
PAGES=43,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes the Message Processing and Dispatching
for Simple Network Management Protocol (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. This document obsoletes RFC 2572. This document is a
product of the SNMPv3 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3412.txt"
}

@TECHREPORT{rfc3413,
AUTHOR="D. Levi and P. Meyer and B. Stewart",
TITLE="Simple Network Management Protocol {(SNMP)} Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3413,
PAGES=74,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes five types of Simple Network
Management Protocol (SNMP) applications which make use of an SNMP engine
as described in STD 62, RFC 3411. The types of application described are
Command Generators, Command Responders, Notification Originators,
Notification Receivers, and Proxy Forwarders. This document also defines
Management Information Base (MIB) modules for specifying targets of
management operations, for notification filtering, and for proxy
forwarding. This document obsoletes RFC 2573. This document is a product
of the SNMPv3 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3413.txt"
}

@TECHREPORT{rfc3414,
AUTHOR="United States Postal Service  and B. Wijnen",
TITLE="User-based Security Model {(USM)} for version 3 of the Simple Network
Management Protocol {(SNMPv3)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3414,
PAGES=88,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes the User-based Security Model (USM)
for Simple Network Management Protocol (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 Management
Information Base (MIB) for remotely monitoring/managing the
configuration parameters for this Security Model. This document
obsoletes RFC 2574. This document is a product of the SNMPv3 Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3414.txt"
}

@TECHREPORT{rfc3415,
AUTHOR="United States Postal Service  and B. Wijnen",
TITLE="View-based Access Control Model {(VACM)} for the Simple Network Management
Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3415,
PAGES=39,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes the View-based Access Control Model
(VACM) for use in the Simple Network Management Protocol (SNMP)
architecture. It defines the Elements of Procedure for controlling
access to management information. This document also includes a
Management Information Base (MIB) for remotely managing the
configuration parameters for the View-based Access Control Model. This
document obsoletes RFC 2575. This document is a product of the SNMPv3
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3415.txt"
}

@TECHREPORT{rfc3416,
EDITOR="R. Presuhn",
TITLE="Version 2 of the Protocol Operations for the Simple Network Management
Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3416,
PAGES=31,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document defines version 2 of the protocol operations for
the Simple Network Management Protocol (SNMP). It defines the syntax and
elements of procedure for sending, receiving, and processing SNMP PDUs.
This document obsoletes RFC 1905. This document is a product of the
SNMPv3 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3416.txt"
}

@TECHREPORT{rfc3417,
EDITOR="R. Presuhn",
TITLE="Transport Mappings for the Simple Network Management Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3417,
PAGES=19,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document defines the transport of Simple Network
Management Protocol (SNMP) messages over various protocols. This
document obsoletes RFC 1906. This document is a product of the SNMPv3
Working Gr oup of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3417.txt"
}

@TECHREPORT{rfc3418,
EDITOR="R. Presuhn",
TITLE="Management Information Base {(MIB)} for the Simple Network Management
Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3418,
PAGES=26,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document defines managed objects which describe the
behavior of a Simple Network Management Protocol (SNMP) entity. This
document obsoletes RFC 1907, Management Information Base for Version 2
of the Simple Network Management Protocol (SNMPv2). This document is a
product of the SNMPv3 Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3418.txt"
}

@TECHREPORT{rfc3419,
AUTHOR="M. Daniele and J. Schoenwaelder",
TITLE="Textual Conventions for Transport Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3419,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document introduces a Management Information Base (MIB)
module that defines textual conventions to represent commonly used
transport-layer addressing information. The definitions are compatible
with the concept of TAddress/TDomain pairs introduced by the Structure
of Management Information version 2 (SMIv2) and support the Internet
transport protocols over IPv4 and IPv6.",
URL="http://www.rfc-editor.org/rfc/rfc3419.txt"
}

@TECHREPORT{rfc3420,
AUTHOR="R. Sparks",
TITLE="Internet Media Type message/sipfrag",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3420,
PAGES=8,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document registers the message/sipfrag Multipurpose
Internet Mail Extensions (MIME) media type. This type is similar to
message/sip, but allows certain subsets of well formed Session
Initiation Protocol (SIP) messages to be represented instead of
requiring a complete SIP message. In addition to end-to-end security
uses, message/sipfrag is used with the REFER method to convey
information about the status of a referenced request. This document is a
product of the Session Initiation Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3420.txt"
}

@TECHREPORT{rfc3421,
AUTHOR="W. Zhao and Henning Schulzrinne and E. Guttman and C. Bisdikian and W.
Jerome",
TITLE="Select and Sort Extensions for the Service Location Protocol {(SLP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3421,
PAGES=8,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document defines two extensions (Select and Sort) for the
Service Location Protocol (SLP). These extensions allow a User Agent
(UA) to request that the Uniform Resource Locator (URL) entries in a
Service Reply (SrvRply) be limited to the specified number, or be sorted
according to the specified sort key list. Using these two extensions
together can facilitate discovering the best match, such as finding a
service that has the maximum speed or the minimum load.",
URL="http://www.rfc-editor.org/rfc/rfc3421.txt"
}

@TECHREPORT{rfc3422,
AUTHOR="O. Okamoto and M. Maruyama and T. Sajima",
TITLE="Forwarding Media Access Control {(MAC)} Frames over Multiple Access
Protocol over Synchronous Optical {Network/Synchronous} Digital Hierarchy
{(MAPOS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3422,
PAGES=19,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This memo describes a method for forwarding media access
control (MAC) frames over Multiple Access Protocol over Synchronous
Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a
way to unify MAPOS network environment and MAC-based Local Area Network
(LAN) environment.",
URL="http://www.rfc-editor.org/rfc/rfc3422.txt"
}

@TECHREPORT{rfc3423,
AUTHOR="K. Zhang and E. Elkin",
TITLE="{XACCT's} Common Reliable Accounting for Network Element {(CRANE)} Protocol
Specification Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3423,
PAGES=45,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document defines the Common Reliable Accounting for
Network Element (CRANE) protocol that enables efficient and reliable
delivery of any data, mainly accounting data from Network Elements to
any systems, such as mediation systems and Business Support Systems
(BSS)/ Operations Support Systems (OSS). The protocol is developed to
address the critical needs for exporting high volume of accounting data
from NE's with efficient use of network, storage, and processing
resources. This document specifies the architecture of the protocol and
the message format, which MUST be supported by all CRANE protocol
implementations.",
URL="http://www.rfc-editor.org/rfc/rfc3423.txt"
}

@TECHREPORT{rfc3424,
EDITOR="L. Daigle and Anton Riabov",
TITLE="{IAB} Considerations for {UNilateral} {Self-Address} Fixing {(UNSAF)}
Across Network Address Translation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3424,
PAGES=9,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT={As a result of the nature of Network Address Translation (NAT)
Middleboxes, communicating endpoints that are separated by one or more
NATs do not know how to refer to themselves using addresses that are
valid in the addressing realms of their (current and future) peers.
Various proposals have been made for {"}UNilateral Self-Address Fixing
(UNSAF){"} processes. These are processes whereby some originating
endpoint attempts to determine or fix the address (and port) by which it
is known to another endpoint - e.g. to be able to use address data in
the protocol exchange, or to advertise a public address from which it
will receive connections. This document outlines the reasons for which
these proposals can be considered at best as short term fixes to
specific problems and the specific issues to be carefully evaluated
before creating an UNSAF proposal. This document is a product of the
Internet Architecture Board.},
URL="http://www.rfc-editor.org/rfc/rfc3424.txt"
}

@TECHREPORT{rfc3425,
AUTHOR="D. Lawrence",
TITLE="Obsoleting {IQUERY}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3425,
PAGES=5,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="The IQUERY method of performing inverse DNS lookups, specified
in RFC 1035, has not been generally implemented and has usually been
operationally disabled where it has been implemented. Both reflect a
general view in the community that the concept was unwise and that the
widely-used alternate approach of using pointer (PTR) queries and
reverse-mapping records is preferable. Consequently, this document
deprecates the IQUERY operation, declaring it entirely obsolete. This
document updates RFC 1035. This document is a product of the DNS
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3425.txt"
}

@TECHREPORT{rfc3426,
AUTHOR="S. Floyd",
TITLE="General Architectural and Policy Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3426,
PAGES=23,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document suggests general architectural and policy
questions that the IETF community has to address when working on new
standards and protocols. We note that this document contains questions
to be addressed, as opposed to guidelines or architectural principles to
be followed.",
URL="http://www.rfc-editor.org/rfc/rfc3426.txt"
}

@TECHREPORT{rfc3427,
AUTHOR="Allison Mankin and S. Bradner and R. Mahy and D. Willis and J. Ott and B.
Rosen",
TITLE="Change Process for the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3427,
PAGES=12,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This memo documents a process intended to apply architectural
discipline to the future development of the Session Initiation Protocol
(SIP). There have been concerns with regards to new SIP proposals.
Specifically, that the addition of new SIP features can be damaging
towards security and/or greatly increase the complexity of the protocol.
The Transport Area directors, along with the SIP and Session Initiation
Proposal Investigation (SIPPING) working group chairs, have provided
suggestions for SIP modifications and extensions.",
URL="http://www.rfc-editor.org/rfc/rfc3427.txt"
}

@TECHREPORT{rfc3428,
EDITOR="B. Campbell and J. Rosenberg and Youjian (Eugene) Eugene Liu",
TITLE="Session Initiation Protocol {(SIP)} Extension for Instant Messaging",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3428,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="Instant Messaging (IM) refers to the transfer of messages
between users in near real-time. These messages are usually, but not
required to be, short. IMs are often used in a conversational mode, that
is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation. This document
proposes the MESSAGE method, an extension to the Session Initiation
Protocol (SIP) that allows the transfer of Instant Messages. Since the
MESSAGE request is an extension to SIP, it inherits all the request
routing and security features of that protocol. MESSAGE requests carry
the content in the form of MIME body parts. MESSAGE requests do not
themselves initiate a SIP dialog; under normal usage each Instant
Message stands alone, much like pager messages. MESSAGE requests may be
sent in the context of a dialog initiated by some other SIP request.
This document is a product of the Session Initiation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3428.txt"
}

@TECHREPORT{rfc3429,
AUTHOR="H. Ohta",
TITLE="Assignment of the {'OAM} Alert Label' for Multiprotocol Label Switching
Architecture {(MPLS)} Operation and Maintenance {(OAM)} Functions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3429,
PAGES=6,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This document describes the assignment of one of the reserved
label values defined in RFC 3032 (MPLS label stack encoding) to the
'Operation and Maintenance (OAM) Alert Label' that is used by user-plane
Multiprotocol Label Switching Architecture (MPLS) OAM functions for
identification of MPLS OAM packets.",
URL="http://www.rfc-editor.org/rfc/rfc3429.txt"
}

@TECHREPORT{rfc3430,
AUTHOR="J. Schoenwaelder",
TITLE="Simple Network Management Protocol Over Transmission Control Protocol
Transport Mapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3430,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This memo defines a transport mapping for using the Simple
Network Management Protocol (SNMP) over TCP. The transport mapping can
be used with any version of SNMP. This document extends the transport
mappings defined in STD 62, RFC 3417.",
URL="http://www.rfc-editor.org/rfc/rfc3430.txt"
}

@TECHREPORT{rfc3431,
AUTHOR="W. Segmuller",
TITLE="Sieve Extension: Relational Tests",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3431,
PAGES=8,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes the RELATIONAL extension to the Sieve
mail filtering language defined in RFC 3028. This extension extends
existing conditional tests in Sieve to allow relational operators. In
addition to testing their content, it also allows for testing of the
number of entities in header and envelope fields.",
URL="http://www.rfc-editor.org/rfc/rfc3431.txt"
}

@TECHREPORT{rfc3432,
AUTHOR="V. I. Raisanen and G. Grotefeld and A. Morton",
TITLE="Network performance measurement with periodic streams",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3432,
PAGES=23,
DAYS=15,
MONTH=nov,
YEAR=2002,
ABSTRACT="This memo describes a periodic sampling method and relevant
metrics for assessing the performance of IP networks. First, the memo
motivates periodic sampling and addresses the question of its value as
an alternative to the Poisson sampling described in RFC 2330. The
benefits include applicability to active and passive measurements,
simulation of constant bit rate (CBR) traffic (typical of multimedia
communication, or nearly CBR, as found with voice activity detection),
and several instances in which analysis can be simplified. The sampling
method avoids predictability by mandating random start times and finite
length tests. Following descriptions of the sampling method and sample
metric parameters, measurement methods and errors are discussed.
Finally, we give additional information on periodic measurements,
including security considerations. This document is a product of the IP
Performance Metrics Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3432.txt"
}

@TECHREPORT{rfc3433,
AUTHOR="A. Bierman and D. Romascanu and K. C. Norseth",
TITLE="Entity Sensor Management Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3433,
PAGES=17,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects for extending the
Entity MIB (RFC 2737) to provide generalized access to information
related to physical sensors, which are often found in networking
equipment (such as chassis temperature, fan RPM, power supply voltage).
This document is a product of the Entity MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3433.txt"
}

@TECHREPORT{rfc3434,
AUTHOR="A. Bierman and K. McCloghrie",
TITLE="Remote Monitoring {MIB} Extensions for High Capacity Alarms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3434,
PAGES=24,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects for extending the
alarm thresholding capabilities found in the Remote Monitoring (RMON)
MIB (RFC 2819), to provide similar threshold monitoring of objects based
on the Counter64 data type. This document is a product of the Remote
Network Monitoring Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3434.txt"
}

@TECHREPORT{rfc3436,
AUTHOR="A. Jungmaier and E. Rescorla and M. Tuexen",
TITLE="Transport Layer Security over Stream Control Transmission Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3436,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes the usage of the Transport Layer
Security (TLS) protocol, as defined in RFC 2246, over the Stream Control
Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The
user of TLS can take advantage of the features provided by SCTP, namely
the support of multiple streams to avoid head of line blocking and the
support of multi-homing to provide network level fault tolerance.
Additionally, discussions of extensions of SCTP are also supported,
meaning especially the support of dynamic reconfiguration of
IP-addresses. This document is a product of the Transport Area Working
Group Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3436.txt"
}

@TECHREPORT{rfc3437,
AUTHOR="W. Palter and W. Townsley",
TITLE="{Layer-Two} Tunneling Protocol Extensions for {PPP} Link Control Protocol
Negotiation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3437,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document defines extensions to the Layer Two Tunneling
Protocol (L2TP) for enhanced support of link-specific Point to Point
Protocol (PPP) options. PPP endpoints typically have direct access to
the common physical media connecting them and thus have detailed
knowledge about the media that is in use. When the L2TP is used, the two
PPP peers are no longer directly connected over the same physical media.
Instead, L2TP inserts a virtual connection over some or all of the PPP
connection by tunneling PPP frames over a packet switched network such
as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP
Link Control Protocol (LCP) options at a location which may not have
access to all of the media information necessary for proper
participation in the LCP negotiation. This document provides a mechanism
for communicating desired LCP options between L2TP endpoints in advance
of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a
mechanism for communicating the negotiated LCP options back to where the
native PPP link resides.",
URL="http://www.rfc-editor.org/rfc/rfc3437.txt"
}

@TECHREPORT{rfc3438,
AUTHOR="W. Townsley",
TITLE="Layer Two Tunneling Protocol {(L2TP)} Internet Assigned Numbers Authority
{(IANA)} Considerations Update",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3438,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes updates to the Internet Assigned
Numbers Authority (IANA) considerations for the Layer Two Tunneling
Protocol (L2TP). This document is a product of the Layer Two Tunneling
Protocol Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3438.txt"
}

@TECHREPORT{rfc3439,
AUTHOR="R. Bush and D. L. Meyer",
TITLE="Some Internet Architectural Guidelines and Philosophy",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3439,
PAGES=28,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document extends RFC 1958 by outlining some of the
philosophical guidelines to which architects and designers of Internet
backbone networks should adhere. We describe the Simplicity Principle,
which states that complexity is the primary mechanism that impedes
efficient scaling, and discuss its implications on the architecture,
design and engineering issues found in large scale Internet backbones.",
URL="http://www.rfc-editor.org/rfc/rfc3439.txt"
}

@TECHREPORT{rfc3440,
AUTHOR="F. Ly and G. Bathrick",
TITLE="Definitions of Extension Managed Objects for Asymmetric Digital Subscriber
Lines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3440,
PAGES=36,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes additional managed objects used
for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not
covered by the ADSL Line MIB (RFC 2662).",
URL="http://www.rfc-editor.org/rfc/rfc3440.txt"
}

@TECHREPORT{rfc3442,
AUTHOR="T. Lemon and S. Cheshire and B. Volz",
TITLE="The Classless Static Route Option for Dynamic Host Configuration Protocol
{(DHCP)} version 4",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3442,
PAGES=9,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document defines a new Dynamic Host Configuration
Protocol (DHCP) option which is passed from the DHCP Server to the DHCP
Client to configure a list of static routes in the client. The network
destinations in these routes are classless - each routing table entry
includes a subnet mask. This document is a product of the Dynamic Host
Configuration Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3442.txt"
}

@TECHREPORT{rfc3445,
AUTHOR="D. Massey and S. Rose",
TITLE="Limiting the Scope of the {KEY} Resource Record {(RR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3445,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document limits the Domain Name System (DNS) KEY Resource
Record (RR) to only keys used by the Domain Name System Security
Extensions (DNSSEC). The original KEY RR used sub-typing to store both
DNSSEC keys and arbitrary application keys. Storing both DNSSEC and
application keys with the same record type is a mistake. This document
removes application keys from the KEY record by redefining the Protocol
Octet field in the KEY RR Data. As a result of removing application
keys, all but one of the flags in the KEY record become unnecessary and
are redefined. Three existing application key sub-types are changed to
reserved, but the format of the KEY record is not changed. This document
updates RFC 2535. This document is a product of the DNS Extensions
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3445.txt"
}

@TECHREPORT{rfc3449,
AUTHOR="H. Balakrishnan and V. Padmanabhan and G. Fairhurst and M. Sooriyabandara",
TITLE="{TCP} Performance Implications of Network Path Asymmetry",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3449,
PAGES=41,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes TCP performance problems that arise
because of asymmetric effects. These problems arise in several access
networks, including bandwidth-asymmetric networks and packet radio
subnetworks, for different underlying reasons. However, the end result
on TCP performance is the same in both cases: performance often degrades
significantly because of imperfection and variability in the ACK
feedback from the receiver to the sender. The document details several
mitigations to these effects, which have either been proposed or
evaluated in the literature, or are currently deployed in networks.
These solutions use a combination of local link-layer techniques,
subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to
manage the channel used for the upstream bottleneck link carrying the
ACKs, typically using header compression or reducing the frequency of
TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain
the TCP sender's acknowledgment-triggered self-clocking and (iii)
techniques to schedule the data and ACK packets in the reverse direction
to improve performance in the presence of two-way traffic. Each
technique is described, together with known issues, and recommendations
for use. A summary of the recommendations is provided at the end of the
document. This document is a product of the Performance Implications of
Link Characteristics Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3449.txt"
}

@TECHREPORT{rfc3450,
AUTHOR="M. Luby and J. Gemmell and L. Vicisano and L. Rizzo and Jon Crowcroft",
TITLE="Asynchronous Layered Coding {(ALC)} Protocol Instantiation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3450,
PAGES=34,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes the Asynchronous Layered Coding (ALC)
protocol, a massively scalable reliable content delivery protocol.
Asynchronous Layered Coding combines the Layered Coding Transport (LCT)
building block, a multiple rate congestion control building block and
the Forward Error Correction (FEC) building block to provide congestion
controlled reliable asynchronous delivery of content to an unlimited
number of concurrent receivers from a single sender. This document is a
product of the Reliable Multicast Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3450.txt"
}

@TECHREPORT{rfc3451,
AUTHOR="M. Luby and J. Gemmell and L. Vicisano and L. Rizzo and M. Handley and Jon
Crowcroft",
TITLE="Layered Coding Transport {(LCT)} Building Block",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3451,
PAGES=29,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="Layered Coding Transport (LCT) provides transport level
support for reliable content delivery and stream delivery protocols. LCT
is specifically designed to support protocols using IP multicast, but
also provides support to protocols that use unicast. LCT is compatible
with congestion control that provides multiple rate delivery to
receivers and is also compatible with coding techniques that provide
reliable delivery of content. This document is a product of the Reliable
Multicast Transport Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3451.txt"
}

@TECHREPORT{rfc3452,
AUTHOR="M. Luby and L. Vicisano and J. Gemmell and L. Rizzo and M. Handley and Jon
Crowcroft",
TITLE="Forward Error Correction {(FEC)} Building Block",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3452,
PAGES=16,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT={This document generally describes how to use Forward Error
Correction (FEC) codes to efficiently provide and/or augment reliability
for data transport. The primary focus of this document is the
application of FEC codes to one-to-many reliable data transport using IP
multicast. This document describes what information is needed to
identify a specific FEC code, what information needs to be communicated
out-of-band to use the FEC code, and what information is needed in data
packets to identify the encoding symbols they carry. The procedures for
specifying FEC codes and registering them with the Internet Assigned
Numbers Authority (IANA) are also described. This document should be
read in conjunction with and uses the terminology of the companion
document titled, {"}The Use of Forward Error Correction (FEC) in Reliable
Multicast{"}. This document is a product of the Reliable Multicast
Transport Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3452.txt"
}

@TECHREPORT{rfc3453,
AUTHOR="M. Luby and L. Vicisano and J. Gemmell and L. Rizzo and M. Handley and Jon
Crowcroft",
TITLE="The Use of Forward Error Correction {(FEC)} in Reliable Multicast",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3453,
PAGES=18,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This memo describes the use of Forward Error Correction (FEC)
codes to efficiently provide and/or augment reliability for one-to-many
reliable data transport using IP multicast. One of the key properties of
FEC codes in this context is the ability to use the same packets
containing FEC data to simultaneously repair different packet loss
patterns at multiple receivers. Different classes of FEC codes and some
of their basic properties are described and terminology relevant to
implementing FEC in a reliable multicast protocol is introduced.
Examples are provided of possible abstract formats for packets carrying
FEC. This document is a product of the Reliable Multicast Transport
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3453.txt"
}

@TECHREPORT{rfc3454,
AUTHOR="P. Hoffman and M. Blanchet",
TITLE={Preparation of Internationalized Strings ({"}stringprep{"})},
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3454,
PAGES=91,
DAYS=15,
MONTH=dec,
YEAR=2002,
ABSTRACT="This document describes a framework for preparing Unicode text
strings in order to increase the likelihood that string input and string
comparison work in ways that make sense for typical users throughout the
world. The stringprep protocol is useful for protocol identifier values,
company and personal names, internationalized domain names, and other
text strings. This document does not specify how protocols should
prepare text strings. Protocols must create profiles of stringprep in
order to fully specify the processing options.",
URL="http://www.rfc-editor.org/rfc/rfc3454.txt"
}

@TECHREPORT{rfc3101,
AUTHOR="P J Murphy",
TITLE="The {OSPF} {Not-So-Stubby} Area {(NSSA)} Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3101,
PAGES=33,
MONTH=jan,
YEAR=2003,
ABSTRACT={This memo documents an optional type of Open Shortest Path First
(OSPF) area that is 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.

The OSPF NSSA Option was originally defined in RFC 1587.  The
functional differences between this memo and RFC 1587 are explained
in Appendix F.  All differences, while expanding capability, are
backward-compatible in nature.  Implementations of this memo and of
RFC 1587 will interoperate.

This document is a product of the Open Shortest Path First IGP Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3101.txt"
}

@TECHREPORT{rfc3199,
AUTHOR="S. Ginoza",
TITLE="Request for Comments Summary",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3199,
MONTH=feb,
YEAR=2003,
URL="http://www.rfc-editor.org/rfc/rfc3199.txt"
}

@TECHREPORT{rfc3313,
AUTHOR="William Marshall and I. W. Ed.",
TITLE="Private Session Initiation Protocol {(SIP)} Extensions for Media
Authorization",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3313,
PAGES=16,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes the need for Quality of Service (QoS) and
media authorization and defines a Session Initiation Protocol (SIP)
extension that can be used to integrate QoS admission control with
call signaling and help guard against denial of service attacks.  The
use of this extension is only applicable in administrative domains, or
among federations of administrative domains with previously
agreed-upon policies, where both the SIP proxy authorizing the QoS,
and the policy control of the underlying network providing the QoS,
belong to that administrative domain or federation of domains.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3313.txt"
}

@TECHREPORT{rfc3315,
AUTHOR="R. E. Droms and I. W. Ed. and Jim Bound and B. Volz and Todd Lemon and
Charles E. Perkins and Megan Carney",
TITLE="Dynamic Host Configuration Protocol for {IPv6} {(DHCPv6)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3315,
PAGES=101,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT={The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables
DHCP servers to pass configuration parameters such as IPv6 network
addresses to IPv6 nodes.  It offers the capability of automatic
allocation of reusable network addresses and additional configuration
flexibility.  This protocol is a stateful counterpart to {"}IPv6
Stateless Address Autoconfiguration{"} (RFC 2462), and can be used
separately or concurrently with the latter to obtain configuration
parameters.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3315.txt"
}

@TECHREPORT{rfc3316,
AUTHOR="J. Arkko and G. Kuijpers and H. Soliman and J. Loughney and J. Wiljakka",
TITLE="Internet Protocol Version 6 {(IPv6)} for Some Second and Third Generation
Cellular Hosts",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3316,
PAGES=22,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="As the deployment of second and third generation cellular networks
progresses, a large number of cellular hosts are being connected to
the Internet.  Standardization organizations are making Internet
Protocol version 6 (IPv6) mandatory in their specifications.  However,
the concept of IPv6 covers many aspects and numerous specifications.
In addition, the characteristics of cellular links in terms of
bandwidth, cost and delay put special requirements on how IPv6 is
used.  This document considers IPv6 for cellular hosts that attach to
the General Packet Radio Service (GPRS), or Universal Mobile
Telecommunications System (UMTS) networks.  This document also lists
basic components of IPv6 functionality and discusses some issues
relating to the use of these components when operating in these
networks.

This document is a product of the IP Version 6 Working Group Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3316.txt"
}

@TECHREPORT{rfc3317,
AUTHOR="Kwong-wing Chan and R. Sahita and S. Hahn and K. McCloghrie",
TITLE="Differentiated Services Quality of Service Policy Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3317,
PAGES=96,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This document describes a Policy Information Base (PIB) for a device
implementing the Differentiated Services Architecture.  The
provisioning classes defined here provide policy control over
resources implementing the Differentiated Services Architecture.
These provisioning classes can be used with other none Differentiated
Services provisioning classes (defined in other PIBs) to provide for a
comprehensive policy controlled mapping of service requirement to
device resource capability and usage.

This document is a product of the Differentiated Services (DIFFSERV)
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3317.txt"
}

@TECHREPORT{rfc3318,
AUTHOR="R. Sahita and I. W. Ed. and S. Hahn and Kwong-wing Chan and K. McCloghrie",
TITLE="Framework Policy Information Base",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3318,
PAGES=70,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This document defines a set of PRovisioning Classes (PRCs) and textual
conventions that are common to all clients that provision policy using
Common Open Policy Service (COPS) protocol for Provisioning.

Structure of Policy Provisioning Information (SPPI) describes a
structure for specifying policy information that can then be
transmitted to a network device for the purpose of configuring
policy at that device.  The model underlying this structure is one
of well-defined (PRCs) and instances of these
classes (PRIs) residing in a virtual information store called the
Policy Information Base (PIB).

One way to provision policy is by means of the (COPS) protocol with
the extensions for provisioning.  This protocol supports multiple
clients, each of which may provision policy for a specific policy
domain such as QoS, virtual private networks, or security.

As described in COPS usage for Policy Provisioning (COPS-PR), each
client supports a non-overlapping and independent set of PIB
modules.  However, some PRovisioning Classes are common to all
subject-categories (client-types) and need to be present in
each.

This document is a product of the Resource Access Protocol (RAP)
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3318.txt"
}

@TECHREPORT{rfc3319,
AUTHOR="Henning Schulzrinne and B. Volz",
TITLE="Dynamic Host Configuration Protocol {(DHCPv6)} Options for Session
Initiation Protocol {(SIP)} Servers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3319,
PAGES=7,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document defines a Dynamic Host Configuration Protocol version 6
(DHCPv6) option that contains a list of domain names or IPv6 addresses
that can be mapped to one or more Session Initiation Protocol (SIP)
outbound proxy servers.  This is one of the many methods that a SIP
client can use to obtain the addresses of such a local SIP server.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3319.txt"
}

@TECHREPORT{rfc3320,
AUTHOR="Roger Price and Carsten Bormann and J. Christoffersson and Hans Hannu and
Zemin Liu and Jonathan Rosenberg",
TITLE="Signaling Compression {(SigComp)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3320,
PAGES=62,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document defines Signaling Compression (SigComp), a solution for
compressing messages generated by application protocols such as the
Session Initiation Protocol (SIP) (RFC 3261) and the Real Time
Streaming Protocol (RTSP) (RFC 2326).  The architecture and
prerequisites of SigComp are outlined, along with the format of the
SigComp message. 

Decompression functionality for SigComp is provided by a Universal
Decompressor Virtual Machine (UDVM) optimized for the task of running
decompression algorithms.  The UDVM can be configured to understand
the output of many well-known compressors such as DEFLATE (RFC-1951).

This document is a product of Robust Header Compression Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3320.txt"
}

@TECHREPORT{rfc3321,
AUTHOR="Hans Hannu and J. Christoffersson and S.  Forsgren and Ka-Cheong Leung and
Zemin Liu and Roger Price",
TITLE="Signaling Compression {(SigComp)} - Extended Operations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3321,
PAGES=19,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes how to implement certain mechanisms in
Signaling Compression (SigComp), RFC 3320, which can significantly
improve the compression efficiency compared to using simple
per-message compression.

SigComp uses a Universal Decompressor Virtual Machine (UDVM) for
decompression, and the mechanisms described in this document are
possible to implement using the UDVM instructions defined in RFC 3320.

This document is a product of the Robust Header Compression Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3321.txt"
}

@TECHREPORT{rfc3322,
AUTHOR="Hans Hannu",
TITLE="Signaling Compression {(SigComp)} Requirements \& Assumptions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3322,
PAGES=13,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="The purpose of this document is to outline requirements and
motivations for the development of a scheme for compression and
decompression of messages from signaling protocols.  In wireless
environments and especially in cellular systems, e.g., GSM (Global
System for Mobile communications) and UMTS (Universal Mobile
Telecommunications System), there is a need to maximize the transport
efficiency for data over the radio interface.  With the introduction
of SIP/SDP (Session Initiation Protocol/Session Description Protocol)
to cellular devices, compression of the signaling messages should be
considered in order to improve both service availability and quality,
mainly by reducing the user idle time, e.g., at call setup.

This document is a product of the Robust Header Compression Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3322.txt"
}

@TECHREPORT{rfc3329,
AUTHOR="J. Arkko and V. Torvinen and Gonzalo  Camarillo and A. Niemi and T.  Haukka",
TITLE="Security Mechanism Agreement for the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3329,
PAGES=24,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document defines new functionality for negotiating the security
mechanisms used between a Session Initiation Protocol (SIP) user
agent and its next-hop SIP entity.  This new functionality
supplements the existing methods of choosing security mechanisms
between SIP entities.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3329.txt"
}

@TECHREPORT{rfc3343,
AUTHOR="M. P. Rose and G. Klyne and D. H. Crocker",
TITLE="The Application Exchange {(APEX)} Presence Service",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3343,
MONTH=apr,
YEAR=2003,
ABSTRACT="This memo describes the Application Exchange (APEX) presence service,
addressed as the well-known endpoint apex=presence. The presence service is
used to manage presence information for APEX endpoints.",
URL="http://www.rfc-editor.org/rfc/rfc3343.txt"
}

@TECHREPORT{rfc3352,
AUTHOR="K. Zeilenga",
TITLE="Connection-less Lightweight Directory Access Protocol {(CLDAP)} to Historic
Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3352,
PAGES=4,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="The Connection-less Lightweight Directory Access Protocol (CLDAP)
technical specification, RFC 1798, was published in 1995 as a Proposed
Standard.  This document discusses the reasons why the CLDAP technical
specification has not been furthered on the Standard Track.  This
document recommends that RFC 1798 be moved to Historic status.",
URL="http://www.rfc-editor.org/rfc/rfc3352.txt"
}

@TECHREPORT{rfc3435,
AUTHOR="Flemming Andreasen and B. Foster",
TITLE="Media Gateway Control Protocol {(MGCP)} Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3435,
PAGES=210,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT={This document describes an application programming interface and a
corresponding protocol (MGCP) which is used between elements of a
decomposed multimedia gateway.  The decomposed multimedia gateway
consists of a Call Agent, which contains the call control
{"}intelligence{"}, and a media gateway which contains the media
functions, e.g., conversion from TDM voice to Voice over IP.

Media gateways contain endpoints on which the Call Agent can create,
modify and delete connections in order to establish and control
media sessions with other multimedia endpoints.  Also, the Call Agent
can instruct the endpoints to detect certain events and generate
signals.  The endpoints automatically communicate changes in service
state to the Call Agent.  Furthermore, the Call Agent can audit
endpoints as well as the connections on endpoints.

The basic and general MGCP protocol is defined in this document,
however most media gateways will need to implement one or more MGCP
packages, which define extensions to the protocol suitable for use
with specific types of media gateways.  Such packages are defined in
separate documents.},
URL="http://www.rfc-editor.org/rfc/rfc3435.txt"
}

@TECHREPORT{rfc3441,
AUTHOR="Raman Kumar",
TITLE="Asynchronous Transfer Mode {(ATM)} Package for the Media Gateway Control
Protocol {(MGCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3441,
PAGES=50,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes an Asynchronous Transfer Mode (ATM) package
for the Media Gateway Control Protocol (MGCP).  This package includes
new Local Connection Options, ATM-specific events and signals, and ATM
connection parameters.  Also included is a description of codec and
profile negotiation.  It extends the MGCP that is currently being
deployed in a number of products.  Implementers should be aware of
developments in the IETF Megaco Working Group and ITU SG16, which are
currently working on a potential successor to this protocol.",
URL="http://www.rfc-editor.org/rfc/rfc3441.txt"
}

@TECHREPORT{rfc3443,
AUTHOR="P. Agarwal and Bora Akyol",
TITLE="Time To Live {(TTL)} Processing in {Multi-Protocol} Label Switching
{(MPLS)} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3443,
PAGES=10,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT={This document describes Time To Live (TTL) processing in hierarchical
Multi-Protocol Label Switching (MPLS) networks and is motivated by the
need to formalize a TTL-transparent mode of operation for an MPLS
label-switched path.  It updates RFC 3032, {"}MPLS Label Stack
Encoding{"}.  TTL processing in both Pipe and Uniform Model hierarchical
tunnels are specified with examples for both {"}push{"} and {"}pop{"}
cases.
The document also complements RFC 3270, {"}MPLS Support of
Differentiated Services{"} and ties together the terminology introduced
in that document with TTL processing in hierarchical MPLS networks.

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3443.txt"
}

@TECHREPORT{rfc3444,
AUTHOR={Aiko Pras and J{\"{u}}rgen {Sch{\"{o}}nw{\"{a}}lder}},
TITLE="On the Difference between Information Models and Data Models",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3444,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="There has been ongoing confusion about the differences between
Information Models and Data Models for defining managed objects in
network management.  This document explains the differences between
these terms by analyzing how existing network management model
specifications (from the IETF and other bodies such as the
International Telecommunication Union (ITU) or the Distributed
Management Task Force (DMTF)) fit into the universe of Information
Models and Data Models.

This memo documents the main results of the 8th workshop of the
Network Management Research Group (NMRG) of the Internet Research
Task Force (IRTF) hosted by the University of Texas at Austin.",
URL="http://www.rfc-editor.org/rfc/rfc3444.txt"
}

@TECHREPORT{rfc3446,
AUTHOR="Dong Kim and D. L. Meyer and H. Kilmer and Dino Farinacci",
TITLE="Anycast Rendevous Point {(RP)} mechanism using Protocol Independent
Multicast {(PIM)} and Multicast Source Discovery Protocol {(MSDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3446,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes a mechanism to allow for an arbitrary number
of Rendevous Points (RPs) per group in a single shared-tree Protocol
Independent Multicast-Sparse Mode (PIM-SM) domain.  

This document is a product of the MBONE Deployment Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3446.txt"
}

@TECHREPORT{rfc3447,
AUTHOR="J. Jonsson and Burton S. Kaliski",
TITLE="{Public-Key} Cryptography Standards {(PKCS)} {#1:} {RSA} Cryptography
Specifications Version {2.1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3447,
PAGES=72,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This memo represents a republication of PKCS #1 v2.1 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and
change control is retained within the PKCS process.  The body of this
document is taken directly from the PKCS #1 v2.1 document, with
certain corrections made during the publication process.",
URL="http://www.rfc-editor.org/rfc/rfc3447.txt"
}

@TECHREPORT{rfc3448,
AUTHOR="Mark Handley and Sally Floyd and Jitendra Padhye and Joerg C. Widmer",
TITLE="{TCP} Friendly Rate Control {(TFRC):} Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3448,
PAGES=24,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document specifies TCP-Friendly Rate Control (TFRC).  TFRC is a
congestion control mechanism for unicast flows
operating in a best-effort Internet environment.  It is
reasonably fair when competing for bandwidth with TCP flows,
but has a much lower variation of throughput over time
compared with TCP, making it more suitable for applications
such as telephony or streaming media where a relatively smooth
sending rate is of importance.

This document is a product of the Transport Area Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3448.txt"
}

@TECHREPORT{rfc3455,
AUTHOR="M. Garcia-Martin and E. Henrikson and David Mills",
TITLE="Private Header {(P-Header)} Extensions to the Session Initiation Protocol
{(SIP)} for the 3rd-Generation Partnership Project {(3GPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3455,
PAGES=34,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes a set of private Session Initiation Protocol
(SIP) headers (P-headers) used by the 3rd-Generation Partnership
Project (3GPP), along with their applicability, which is limited to
particular environments.  The P-headers are for a variety of purposes
within the networks that the partners use, including charging and
information about the networks a call traverses.",
URL="http://www.rfc-editor.org/rfc/rfc3455.txt"
}

@TECHREPORT{rfc3456,
AUTHOR="Baiju Patel and Bernard D Aboba and S. Kelly and Vipul Gupta",
TITLE="Dynamic Host Configuration Protocol {(DHCPv4)} Configuration of {IPsec}
Tunnel Mode",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3456,
PAGES=18,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT={This memo explores the requirements for host configuration in IPsec
tunnel mode, and describes how the Dynamic Host Configuration Protocol
(DHCPv4) may be leveraged for configuration.  In many remote access
scenarios, a mechanism for making the remote host appear to be present
on the local corporate network is quite useful.  This may be
accomplished by assigning the host a {"}virtual{"} address from the
corporate network, and then tunneling traffic via IPsec from the
host's ISP-assigned address to the corporate security gateway.  In
IPv4, DHCP provides for such remote host configuration.

This document is a product of the IPSEC Remote Access (IPSRA) Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3456.txt"
}

@TECHREPORT{rfc3457,
AUTHOR="S. Kelly and S. Ramamoorthi",
TITLE="Requirements for {IPsec} Remote Access Scenarios",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3457,
PAGES=31,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="IPsec offers much promise as a secure remote access mechanism.
However, there are a number of differing remote access scenarios,
each having some shared and some unique requirements.  A thorough
understanding of these requirements is necessary in order to
effectively evaluate the suitability of a specific set of mechanisms
for any particular remote access scenario.  This document enumerates
the requirements for a number of common remote access scenarios.

This document is a product of the IPSEC Remote Access (IPSRA) Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3457.txt"
}

@TECHREPORT{rfc3458,
AUTHOR="E. Burger and E. Candell and C. Eliot and G. Klyne",
TITLE="Message Context for Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3458,
PAGES=17,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT={This memo describes a new RFC 2822 message header, {"}Message-Context{"}.
This header provides information about the context and presentation
characteristics of a message.

A receiving user agent (UA) may use this information as a hint to
optimally present the message.

This document is a product of the Voice Profile for Internet Mail
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3458.txt"
}

@TECHREPORT{rfc3459,
AUTHOR="E. Burger",
TITLE="Critical Content Multi-purpose Internet Mail Extensions {(MIME)} Parameter",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3459,
PAGES=24,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes the use of a mechanism for identifying body
parts that a sender deems critical in a multi-part Internet mail
message.  The mechanism described is a parameter to
Content-Disposition, as described by RFC 3204.

By knowing what parts of a message the sender deems critical, a
content gateway can intelligently handle multi-part messages when
providing gateway services to systems of lesser
capability.  Critical content can help a content gateway to decide
what parts to forward.  It can indicate how hard a gateway should try
to deliver a body part.  It can help the gateway to pick body parts
that are safe to silently delete when a system of lesser
capability receives a message.  In addition, critical content can
help the gateway chose the notification strategy for the receiving
system.  Likewise, if the sender expects the destination to do
some processing on a body part, critical content allows the sender
to mark body parts that the receiver must process.

This document is a product of the Voice Profile for Internet Mail
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3459.txt"
}

@TECHREPORT{rfc3460,
AUTHOR="B. W. Moore and I. W. Ed.",
TITLE="Policy Core Information Model {(PCIM)} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3460,
PAGES=93,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document specifies a number of changes to the Policy Core
Information Model (PCIM, RFC 3060).  Two types of changes are
included.  First, several completely new elements are introduced, for
example, classes for header filtering, that extend PCIM into areas
that it did not previously cover.  Second, there are cases where
elements of PCIM (for example, policy rule priorities) are deprecated,
and replacement elements are defined (in this case, priorities tied to
associations that refer to policy rules).  Both types of changes are
done in such a way that, to the extent possible, interoperability with
implementations of the original PCIM model is preserved.  This
document updates RFC 3060.

This document is a product of the Policy Framework Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3460.txt"
}

@TECHREPORT{rfc3461,
AUTHOR="K. {Moore(at)cs.utk.edu draft-moore-rfc1891bis-} and  {which allows an
client to specify that S}",
TITLE="Simple Mail Transfer Protocol {(SMTP)} Service Extension for Delivery
Status Notifications {(DSNs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3461,
PAGES=38,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This memo defines an extension to the Simple Mail Transfer Protocol
(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.",
URL="http://www.rfc-editor.org/rfc/rfc3461.txt"
}

@TECHREPORT{rfc3462,
AUTHOR="G. M. Vaudreuil",
TITLE="The {Multipart/Report} Content Type for the Reporting of Mail System
Administrative Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3462,
PAGES=7,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT={The Multipart/Report Multipurpose Internet Mail Extensions (MIME)
content-type is a general {"}family{"} or {"}container{"} type for
electronic
mail reports of any kind.  Although this memo defines only the use of
the Multipart/Report content-type with respect to delivery status
reports, mail processing programs will benefit if a single
content-type is used to for all kinds of reports.

This document is part of a four document set describing the delivery
status report service.  This collection includes the Simple Mail
Transfer Protocol (SMTP) extensions to request delivery status
reports, a MIME content for the reporting of delivery reports, an
enumeration of extended status codes, and a multipart container for
the delivery report, the original message, and a human-friendly
summary of the failure.},
URL="http://www.rfc-editor.org/rfc/rfc3462.txt"
}

@TECHREPORT{rfc3464,
AUTHOR="Keith Moore and G. {Moore(at)cs.utk.edu} and 
{Draft-vaudreuil-1894bis-02.txt ftp://ftp} and  {the Delivery}",
TITLE="An Extensible Message Format for Delivery Status Notifications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3464,
PAGES=40,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT={This memo defines a Multipurpose Internet Mail Extensions (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.

Because many messages are sent between the Internet and other
messaging systems (such as X.400 or the so-called {"}Local Area Network
(LAN)-based{"} systems), the Delivery Status Notification (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.},
URL="http://www.rfc-editor.org/rfc/rfc3464.txt"
}

@TECHREPORT{rfc3465,
AUTHOR="M. Allman",
TITLE="{TCP} Congestion Control with Appropriate Byte Counting {(ABC)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3465,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document proposes a small modification to the way TCP increases its
congestion window. Rather than the traditional method of increasing the
congestion window by a constant amount for each arriving acknowledgment,
the document suggests basing the increase on the number of previously
unacknowledged bytes each ACK covers. This change improves the performance
of TCP, as well as closes a security hole TCP receivers can use to induce
the sender into increasing the sending rate too rapidly.",
URL="http://www.rfc-editor.org/rfc/rfc3465.txt"
}

@TECHREPORT{rfc3466,
AUTHOR="Mark Day and Brad Cain and G. Tomlinson and P. Rzewski",
TITLE="A Model for Content Internetworking {(CDI)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3466,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT={Content (distribution) internetworking (CDI) is the technology for
interconnecting content networks, sometimes previously called
{"}content peering{"} or {"}CDN peering{"}.  A common vocabulary helps the
process of discussing such interconnection and interoperation.  This
document introduces content networks and content internetworking, and
defines elements for such a common vocabulary.

This document is a product of the Content Distribution Internetworking
(cdi) Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3466.txt"
}

@TECHREPORT{rfc3467,
AUTHOR="J. Klensin",
TITLE="Role of the Domain Name System {(DNS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3467,
PAGES=31,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document reviews the original function and purpose of the domain
name system (DNS).  It contrasts that history with some of the
purposes for which the DNS has recently been applied and some of the
newer demands being placed upon it or suggested for it.  A framework
for an alternative to placing these additional stresses on the DNS is
then outlined.  This document and that framework are not a proposed
solution, only a strong suggestion that the time has come to begin
thinking more broadly about the problems we are encountering and
possible approaches to solving them.",
URL="http://www.rfc-editor.org/rfc/rfc3467.txt"
}

@TECHREPORT{rfc3468,
AUTHOR="L. Andersson and George Swallow",
TITLE="The Multiprotocol Label Switching {(MPLS)} Working Group decision on {MPLS}
signaling protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3468,
PAGES=11,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT={This document documents the consensus reached by the Multiprotocol
Label Switching (MPLS) Working Group within the IETF to focus its
efforts on {"}Resource Reservation Protocol (RSVP)-TE: Extensions to
RSVP for Label-Switched Paths (LSP) Tunnels{"} (RFC 3209) as the MPLS
signalling protocol for traffic engineering applications and to
undertake no new efforts relating to {"}Constraint-Based LSP Setup using
Label Distribution Protocol (LDP){"} (RFC 3212).  The recommendations of
section 6 have been accepted by the IESG.

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3468.txt"
}

@TECHREPORT{rfc3469,
AUTHOR="Vinod Sharma and F. Hellstrand",
TITLE="Framework for {Multi-Protocol} Label Switching {(MPLS)-based} Recovery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3469,
PAGES=40,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="Multi-protocol label switching (MPLS) integrates the label swapping
forwarding paradigm with network layer routing.  To deliver reliable
service, MPLS requires a set of procedures to provide protection of
the traffic carried on different paths.  This requires that the label
switching routers (LSRs) support fault detection, fault notification,
and fault recovery mechanisms, and that MPLS signaling support the
configuration of recovery.  With these objectives in mind, this
document specifies a framework for MPLS based recovery.  Restart
issues are not included in this framework.

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3469.txt"
}

@TECHREPORT{rfc3470,
AUTHOR="S. Hollenbeck and M. P. Rose and L. Masinter",
TITLE="Guidelines for the Use of Extensible Markup Language {(XML)} within {IETF}
Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3470,
MONTH=jan,
YEAR=2003,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc3470.txt"
}

@TECHREPORT{rfc3471,
AUTHOR="Lou Berger",
TITLE="Generalized {Multi-Protocol} Label Switching {(GMPLS)} Signaling Functional
Description",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3471,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes extensions to Multi-Protocol Label Switching (MPLS)
signaling required to support Generalized MPLS. Generalized MPLS extends
the MPLS control plane to encompass time-division (e.g., Synchronous
Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength
(optical lambdas) and spatial switching (e.g., incoming port or fiber to
outgoing port or fiber). This document presents a functional description of
the extensions. Protocol specific formats and mechanisms, and technology
specific details are specified in separate documents.",
URL="http://www.rfc-editor.org/rfc/rfc3471.txt"
}

@TECHREPORT{rfc3472,
AUTHOR="Peter  Ashwood-Smith and Lou Berger and   Editors",
TITLE="Generalized {Multi-Protocol} Label Switching {(GMPLS)} Signaling
Constraint-based Routed Label Distribution Protocol {(CR-LDP)} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3472,
PAGES=23,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes extensions to Multi-Protocol Label Switching
(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP)
signaling required to support Generalized MPLS.  Generalized
MPLS extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber).  This document
presents a CR-LDP specific description of the extensions.  A generic
functional description can be found in separate documents.

This document is a product of the Common Control and Measurement Plane
(ccamp) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3472.txt"
}

@TECHREPORT{rfc3473,
AUTHOR="Lou Berger and Rfc Editor",
TITLE="Generalized {Multi-Protocol} Label Switching {(GMPLS)} Signaling Resource
{ReserVation} {Protocol-Traffic} Engineering {(RSVP-TE)} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3473,
PAGES=42,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="This document describes extensions to Multi-Protocol Label Switching
(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
signaling required to support Generalized MPLS.  Generalized MPLS
extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber).  This document
presents a RSVP-TE specific description of the extensions.  A generic
functional description can be found in separate documents.

This document is a product of the Common Control and Measurement Plane
(ccamp) Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3473.txt"
}

@TECHREPORT{rfc3474,
AUTHOR="Zhenghan Lin and Dimitrios Pendarakis",
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)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3474,
PAGES=25,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="The Generalized MultiProtocol Label Switching (GMPLS) suite of
protocol specifications has been defined to provide support for
different technologies as well as different applications.  These
include support for requesting TDM connections based on Synchronous
Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as
well as Optical Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS
suite of protocols, specifically GMPLS signaling using Resource
Reservation Protocol - Traffic Engineering (RSVP-TE).  It
proposes additional extensions to these signaling protocols to
support the capabilities of an ASON network.

This document proposes appropriate extensions towards the resolution
of additional requirements identified and communicated by the ITU-T
Study Group 15 in support of ITU's ASON standardization effort.",
URL="http://www.rfc-editor.org/rfc/rfc3474.txt"
}

@TECHREPORT{rfc3475,
AUTHOR="O. S. Aboul-Magd",
TITLE="Documentation of {IANA} assignments for Constraint Route Label Distribution
Protocol {(CR-LDP)} Extensions for Automatic Switched Optical Network
{(ASON)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3475,
PAGES=13,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="Automatic Switched Optical Network (ASON) is an architecture,
specified by ITU-T Study Group 15, for the introduction of a
control plane for optical networks.  The ASON architecture specifies
a set of reference points that defines the relationship between the
ASON architectural entities.  Signaling over interfaces defined in
those reference points can make use of protocols that are defined
by the IETF in the context of Generalized Multi-Protocol Label
Switching (GMPLS) work.  This document describes Constraint-Based
LSP setup using LDP (CR-LDP) extensions for signaling over the
interfaces defined in the ASON reference points.  The purpose of
the document is to request that the IANA assigns code points
necessary for the CR-LDP extensions.  The protocol specifications
for the use of the CR-LDP extensions are found in ITU-T documents.",
URL="http://www.rfc-editor.org/rfc/rfc3475.txt"
}

@TECHREPORT{rfc3476,
AUTHOR="Bala Rajagopalan",
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",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3476,
PAGES=11,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="The Optical Interworking Forum (OIF) has defined extensions to the
Label Distribution Protocol (LDP) and the Resource ReSerVation
Protocol (RSVP) for optical User Network Interface (UNI)
signaling.  These extensions consist of a set of new data objects and
error codes.  This document describes these extensions.",
URL="http://www.rfc-editor.org/rfc/rfc3476.txt"
}

@TECHREPORT{rfc3477,
AUTHOR="Kireeti  Kompella and Y. Rekhter",
TITLE="Signalling Unnumbered Links in Resource {ReSerVation} Protocol - Traffic
Engineering {(RSVP-TE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3477,
PAGES=9,
DAYS=15,
MONTH=jan,
YEAR=2003,
ABSTRACT="Current signalling used by Multi-Protocol Label Switching Traffic
Engineering (MPLS TE) does not provide support for unnumbered
links.  This document defines procedures and extensions to
Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP)
Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are
needed in order to support unnumbered links.

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3477.txt"
}

@TECHREPORT{rfc3478,
AUTHOR="M. Leelanivas and Y. Rekhter and Rahul Aggarwal",
TITLE="Graceful Restart Mechanism for Label Distribution Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3478,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document describes a mechanism that helps to minimize the
negative effects on MPLS traffic caused by Label Switching Router's
(LSR's) control plane restart, specifically by the restart of its
Label Distribution Protocol (LDP) component, on LSRs that are capable
of preserving the MPLS forwarding component across the restart.

The mechanism described in this document is applicable to all LSRs,
both those with the ability to preserve forwarding state during LDP
restart and those without (although the latter needs to implement only
a subset of the mechanism described in this document).  Supporting (a
subset of) the mechanism described here by the LSRs that can not
preserve their MPLS forwarding state across the restart would not
reduce the negative impact on MPLS traffic caused by their control
plane restart, but it would minimize the impact if their neighbor(s)
are capable of preserving the forwarding state across the restart of
their control plane and implement the mechanism described here.

The mechanism makes minimalistic assumptions on what has to be
preserved across restart - the mechanism assumes that only the actual
MPLS forwarding state has to be preserved; the mechanism does not
require any of the LDP-related states to be preserved across the
restart.

The procedures described in this document apply to downstream
unsolicited label distribution.  Extending these procedures to
downstream on demand label distribution is for further study.

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3478.txt"
}

@TECHREPORT{rfc3479,
AUTHOR="A. Farrel and I. W. Ed.",
TITLE="Fault Tolerance for the Label Distribution Protocol {(LDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3479,
PAGES=52,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT={Multiprotocol Label Switching (MPLS) systems will be used
in core networks where system downtime must be kept to an
absolute minimum.  Many MPLS Label Switching Routers
(LSRs) may, therefore, exploit Fault Tolerant (FT)
hardware or software to provide high availability of the
core networks.

The details of how FT is achieved for the various
components of an FT LSR, including Label Distribution
Protocol (LDP), the switching hardware and TCP, are
implementation specific.  This document identifies issues
in the LDP specification in RFC 3036, {"}LDP Specification{"},
that make it difficult to implement an FT LSR using the
current LDP protocols, and defines enhancements to the
LDP specification to ease such FT LSR implementations.

The issues and extensions described here are equally
applicable to RFC 3212, {"}Constraint-Based LSP Setup Using
LDP{"} (CR-LDP).

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3479.txt"
}

@TECHREPORT{rfc3480,
AUTHOR="Kireeti  Kompella and Y. Rekhter and A. Kullberg",
TITLE="Signalling Unnumbered Links in {CR-LDP} {(Constraint-Routing} Label
Distribution Protocol)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3480,
PAGES=8,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="Current signalling used by Multi-Protocol Label Switching Traffic
Engineering (MPLS TE) does not provide support for unnumbered links.
This document defines procedures and extensions to Constraint-Routing
Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling
protocols that are needed in order to support unnumbered links.

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3480.txt"
}

@TECHREPORT{rfc3481,
AUTHOR="Ed. H. Inamura and Ed. G. Montenegro and R. Ludwig and Andrei Gurtov and F.
Khafizov",
TITLE="{TCP} over Second {(2.5G)} and Third {(3G)} Generation Wireless Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3481,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document describes a profile for optimizing TCP to adapt so that it
handles paths including second (2.5G) and third (3G) generation wireless
networks. It describes the relevant characteristics of 2.5G and 3G
networks, and specific features of example deployments of such networks. It
then recommends TCP algorithm choices for nodes known to be starting or
ending on such paths, and it also discusses open issues. The configuration
options recommended in this document are commonly found in modern TCP
stacks, and are widely available standards-track mechanisms that the
community considers safe for use on the general Internet.",
URL="http://www.rfc-editor.org/rfc/rfc3481.txt"
}

@TECHREPORT{rfc3482,
AUTHOR="Mark Foster and T. McGarry and Jie Yu",
TITLE="Number Portability in the Global Switched Telephone Network {(GSTN):} An
Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3482,
PAGES=30,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document provides an overview of E.164 telephone number
portability (NP) in the Global Switched Telephone Network
(GSTN).

NP is a regulatory imperative seeking to liberalize local
telephony service competition, by enabling end-users to retain
telephone numbers while changing service providers.  NP changes the
fundamental nature of a dialed E.164 number from a hierarchical
physical routing address to a virtual address, thereby requiring the
transparent translation of the later to the former.  In addition,
there are various regulatory constraints that establish relevant
parameters for NP implementation, most of which are not network
technology specific.  Consequently, the implementation of NP
behavior consistent with applicable regulatory constraints, as well
as the need for interoperation with the existing GSTN NP
implementations, are relevant topics for numerous areas of IP
telephony works-in-progress with the IETF.

This document is a product of the Telephone Number Mapping Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3482.txt"
}

@TECHREPORT{rfc3483,
AUTHOR="D. Rawlins and Amit Kulkarni and M. Bokaemper and Kwong-wing Chan",
TITLE="Framework for Policy Usage Feedback for Common Open Policy Service with
Policy Provisioning {(COPS-PR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3483,
PAGES=10,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="Common Open Policy Services (COPS) Protocol (RFC 2748), defines the
capability of reporting information to the Policy Decision Point
(PDP).  The types of report information are success, failure and
accounting of an installed state.  This document focuses on the COPS
Report Type of Accounting and the necessary framework for the
monitoring and reporting of usage feedback for an installed state.

This document is a product of the Resource Allocation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3483.txt"
}

@TECHREPORT{rfc3484,
AUTHOR="Richard Draves",
TITLE="Default Address Selection for Internet Protocol version 6 {(IPv6)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3484,
PAGES=24,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document describes two algorithms, for source address selection
and for destination address selection.  The algorithms specify default
behavior for all Internet Protocol version 6 (IPv6) implementations.
They do not override choices made by applications or upper-layer
protocols, nor do they preclude the development of more advanced
mechanisms for address selection.  The two algorithms share a common
context, including an optional mechanism for allowing administrators
to provide policy that can override the default behavior.  In dual
stack implementations, the destination address selection algorithm can
consider both IPv4 and IPv6 addresses - depending on the available
source addresses, the algorithm might prefer IPv6 addresses over IPv4
addresses, or vice-versa.

All IPv6 nodes, including both hosts and routers, must implement
default address selection as defined in this specification.

This document is a product of the IP Version 6 Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3484.txt"
}

@TECHREPORT{rfc3485,
AUTHOR="M. Garcia-Martin and Carsten Bormann and Joerg Ott and Roger Price and A.
B. Roach",
TITLE="The Session Initiation Protocol {(SIP)} and Session Description Protocol
{(SDP)} Static Dictionary for Signaling Compression {(SigComp)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3485,
PAGES=30,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="The Session Initiation Protocol (SIP) is a text-based protocol for
initiating and managing communication sessions.  The protocol can be
compressed by using Signaling Compression (SigComp).  Similarly, the
Session Description Protocol (SDP) is a text-based protocol intended
for describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia
session initiation.  This memo defines the SIP/SDP-specific static
dictionary that SigComp may use in order to achieve higher efficiency.
The dictionary is compression algorithm independent.

This document is a product of the Session Initiation Proposal
Investigation Working Group and the Session Initiation Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3485.txt"
}

@TECHREPORT{rfc3485,
AUTHOR="M. Garcia-Martin and Carsten Bormann and Joerg Ott and Roger Price and A.
B. Roach",
TITLE="The Session Initiation Protocol {(SIP)} and Session Description Protocol
{(SDP)} Static Dictionary for Signaling Compression {(SigComp)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3485,
PAGES=30,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="The Session Initiation Protocol (SIP) is a text-based protocol for
initiating and managing communication sessions.  The protocol can be
compressed by using Signaling Compression (SigComp).  Similarly, the
Session Description Protocol (SDP) is a text-based protocol intended
for describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia
session initiation.  This memo defines the SIP/SDP-specific static
dictionary that SigComp may use in order to achieve higher efficiency.
The dictionary is compression algorithm independent.

This document is a product of the Session Initiation Proposal
Investigation Working Group and the Session Initiation Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3485.txt"
}

@TECHREPORT{rfc3486,
AUTHOR="Gonzalo  Camarillo",
TITLE="Compressing the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3486,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document describes a mechanism to signal that compression is
desired for one or more Session Initiation Protocol
(SIP) messages.  It also states when it is appropriate to send
compressed SIP messages to a SIP entity.

This document is a product of the Session Initiation Proposal
Investigation Working Group and the Session Initiation Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3486.txt"
}

@TECHREPORT{rfc3486,
AUTHOR="Gonzalo  Camarillo",
TITLE="Compressing the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3486,
PAGES=12,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document describes a mechanism to signal that compression is
desired for one or more Session Initiation Protocol
(SIP) messages.  It also states when it is appropriate to send
compressed SIP messages to a SIP entity.

This document is a product of the Session Initiation Proposal
Investigation Working Group and the Session Initiation Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3486.txt"
}

@TECHREPORT{rfc3487,
AUTHOR="Henning Schulzrinne",
TITLE="Requirements for Resource Priority Mechanisms for the Session Initiation
Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3487,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document summarizes requirements for prioritizing access to
circuit-switched network, end system and proxy resources for
emergency preparedness communications using the Session Initiation
Protocol (SIP).

This document is a product of the Internet Emergency Preparedness
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3487.txt"
}

@TECHREPORT{rfc3488,
AUTHOR="I. Wu and T. Eckert",
TITLE="Cisco Systems Router-port Group Management Protocol {(RGMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3488,
PAGES=17,
DAYS=15,
MONTH=feb,
YEAR=2003,
ABSTRACT="This document describes the Router-port Group Management Protocol
(RGMP).  This protocol was developed by Cisco Systems and is used
between multicast routers and switches to restrict multicast packet
forwarding in switches to those routers where the packets may be
needed.

RGMP is designed for backbone switched networks where multiple, high
speed routers are interconnected.",
URL="http://www.rfc-editor.org/rfc/rfc3488.txt"
}

@TECHREPORT{rfc3489,
AUTHOR="Jonathan Rosenberg and J. Weinberger and Christian Huitema and R. Mahy",
TITLE="{STUN} - Simple Traversal of User Datagram Protocol {(UDP)} Through Network
Address Translators {(NATs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3489,
PAGES=47,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs) (STUN) is a lightweight protocol that
allows applications to discover the presence and types of NATs and
firewalls between them and the public Internet.  It also provides the
ability for applications to determine the public Internet Protocol
(IP) addresses allocated to them by the NAT.  STUN works with many
existing NATs, and does not require any special behavior from them.
As a result, it allows a wide variety of applications to work through
existing NAT infrastructure.

This document is a product of the Middlebox Communication Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3489.txt"
}

@TECHREPORT{rfc3490,
AUTHOR="P. Faltstrom and Paul Hoffman and Adam Costello",
TITLE="Internationalizing Domain Names in Applications {(IDNA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3490,
PAGES=22,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="Until now, there has been no standard method for domain names to use
characters outside the ASCII repertoire.  This document defines
internationalized domain names (IDNs) and a mechanism called
Internationalizing Domain Names in Applications (IDNA) for
handling them in a standard fashion.  IDNs use characters drawn from a
large repertoire (Unicode), but IDNA allows the non-ASCII characters
to be represented using only the ASCII characters already allowed in
so-called host names today.  This backward-compatible representation
is required in existing protocols like DNS, so that IDNs can be
introduced with no changes to the existing infrastructure.  IDNA is
only meant for processing domain names, not free text.

This document is a product of the Internationalized Domain Name
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3490.txt"
}

@TECHREPORT{rfc3491,
AUTHOR="Paul Hoffman and M. Blanchet",
TITLE="Nameprep: A Stringprep Profile for Internationalized Domain Names {(IDN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3491,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This document describes how to prepare internationalized domain name
(IDN) labels in order to increase the likelihood that name input and
name comparison work in ways that make sense for typical users
throughout the world.  This profile of the stringprep protocol is used
as part of a suite of on-the-wire protocols for internationalizing the
Domain Name System (DNS).

This document is a product of the Internationalized Domain Name
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3491.txt"
}

@TECHREPORT{rfc3492,
AUTHOR="Adam Costello",
TITLE="Punycode: A Bootstring encoding of Unicode for Internationalized Domain
Names in Applications {(IDNA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3492,
PAGES=35,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="Punycode is a simple and efficient transfer encoding syntax designed
for use with Internationalized Domain Names in Applications
(IDNA).  It uniquely and reversibly transforms a Unicode string into
an ASCII string.  ASCII characters in the Unicode string are
represented literally, and non-ASCII characters are represented by
ASCII characters that are allowed in host name labels (letters,
digits, and hyphens).  This document defines a general algorithm
called Bootstring that allows a string of basic code points to
uniquely represent any string of code points drawn from a larger set.
Punycode is an instance of Bootstring that uses particular parameter
values specified by this document, appropriate for IDNA.

This document is a product of the Internationalized Domain Name
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3492.txt"
}

@TECHREPORT{rfc3493,
AUTHOR="R. Gilligan and Sue Thomson and Jim Bound and J. McCann and W. Richard
Stevens",
TITLE="Basic Socket Interface Extensions for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3493,
PAGES=39,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT={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.

This document is a product of the IP Version 6 Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3493.txt"
}

@TECHREPORT{rfc3494,
AUTHOR="K. Zeilenga",
TITLE="Lightweight Directory Access Protocol version 2 {(LDAPv2)} to Historic
Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3494,
PAGES=5,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This document recommends the retirement of version 2 of the
Lightweight Directory Access Protocol (LDAPv2) and other dependent
specifications, and discusses the reasons for doing so.  This document
recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents
they superseded) be moved to Historic status.",
URL="http://www.rfc-editor.org/rfc/rfc3494.txt"
}

@TECHREPORT{rfc3495,
AUTHOR="B. Beser and P. Duffy and I. W. Ed.",
TITLE="Dynamic Host Configuration Protocol {(DHCP)} Option for {CableLabs} Client
Configuration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3495,
PAGES=13,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This document defines a Dynamic Host Configuration Protocol (DHCP)
option that will be used to configure various devices deployed within
CableLabs architectures.  Specifically, the document describes DHCP
option content that will be used to configure one class of CableLabs
client device: a PacketCable Media Terminal Adapter (MTA).  The option
content defined within this document will be extended as future
CableLabs client devices are developed.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3495.txt"
}

@TECHREPORT{rfc3496,
AUTHOR="Andrew G. Malis and T. Hsiao",
TITLE="Protocol Extension for Support of Asynchronous Transfer Mode {(ATM)}
Service Class-aware Multiprotocol Label Switching {(MPLS)} Traffic
Engineering",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3496,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This document specifies a Resource ReSerVation Protocol-Traffic
Engineering (RSVP-TE) signaling extension for support of Asynchronous
Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching
(MPLS) Traffic Engineering.",
URL="http://www.rfc-editor.org/rfc/rfc3496.txt"
}

@TECHREPORT{rfc3497,
AUTHOR="Ladan Gharai and Charles E. Perkins and G. Goncher and Allison Mankin",
TITLE="{RTP} Payload Format for Society of Motion Picture and Television Engineers
{(SMPTE)} {292M} Video",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3497,
PAGES=12,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This memo specifies an RTP payload format for encapsulating
uncompressed High Definition Television (HDTV) as defined by the
Society of Motion Picture and Television Engineers (SMPTE) standard,
SMPTE 292M.  SMPTE is the main standardizing body in the motion
imaging industry and the SMPTE 292M standard defines a bit-serial
digital interface for local area HDTV transport.

This document is a product of the Audio/Video Transport Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3497.txt"
}

@TECHREPORT{rfc3498,
AUTHOR="J. Kuhfeld and J. D. Johnson and M. Thatcher",
TITLE="Definitions of Managed Objects for Synchronous Optical Network {(SONET)}
Linear Automatic Protection Switching {(APS)} Architectures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3498,
PAGES=43,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets.
In particular, it defines objects for managing networks using
Synchronous Optical Network (SONET) linear Automatic Protection
Switching (APS) architectures.

This document is a product of the AToM MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3498.txt"
}

@TECHREPORT{rfc3501,
AUTHOR="M. R. Crispin",
TITLE="{INTERNET} {MESSAGE} {ACCESS} {PROTOCOL} - {VERSION} 4rev1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3501,
PAGES=108,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows
a client to access and manipulate electronic mail messages on a
server.  IMAP4rev1 permits manipulation of mailboxes (remote message
folders) in a way that is functionally equivalent to local folders.
IMAP4rev1 also provides the capability for an offline client to
resynchronize with the server.

IMAP4rev1 includes operations for creating, deleting, and renaming
mailboxes, checking for new messages, permanently removing messages,
setting and clearing flags, RFC 2822 and RFC 2045 parsing,
searching, and selective fetching of message attributes, texts, and
portions thereof.  Messages in IMAP4rev1 are accessed by the use of
numbers.  These numbers are either message sequence numbers or unique
identifiers.

IMAP4rev1 supports a single server.  A mechanism for accessing
configuration information to support multiple IMAP4rev1 servers is
discussed in RFC 2244.

IMAP4rev1 does not specify a means of posting mail; this function is
handled by a mail transfer protocol such as RFC 2821.",
URL="http://www.rfc-editor.org/rfc/rfc3501.txt"
}

@TECHREPORT{rfc3502,
AUTHOR="M. R. Crispin",
TITLE="Internet Message Access Protocol {(IMAP)} - {MULTIAPPEND} Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3502,
PAGES=7,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT={This document describes the multiappending extension to the Internet
Message Access Protocol (IMAP) (RFC 3501).  This extension
provides substantial performance improvements for IMAP clients which
upload multiple messages at a time to a mailbox on the server.

A server which supports this extension indicates this with a
capability name of {"}MULTIAPPEND{"}.},
URL="http://www.rfc-editor.org/rfc/rfc3502.txt"
}

@TECHREPORT{rfc3503,
AUTHOR="A. Melnikov",
TITLE="Message Disposition Notification {(MDN)} profile for Internet Message
Access Protocol {(IMAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3503,
PAGES=9,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="The Message Disposition Notification (MDN) facility defined in RFC
2298 provides a means by which a message can request that message
processing by the recipient be acknowledged as well as a format to be
used for such acknowledgements.  However, it doesn't describe how
multiple Mail User Agents (MUAs) should handle the generation of MDNs
in an Internet Message Access Protocol (IMAP4) environment.

This document describes how to handle MDNs in such an environment and
provides guidelines for implementers of IMAP4 that want to add MDN
support to their products.",
URL="http://www.rfc-editor.org/rfc/rfc3503.txt"
}

@TECHREPORT{rfc3504,
AUTHOR="D. Eastlake",
TITLE="Internet Open Trading Protocol {(IOTP)} Version {1,} Errata",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3504,
PAGES=6,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="Since the publication of the RFCs specifying Version 1.0 of the
Internet Open Trading Protocol (IOTP), some errors have been noted.
This informational document lists these errors and provides
corrections for them.

This document is a product of the Internet Open Trading Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3504.txt"
}

@TECHREPORT{rfc3505,
AUTHOR="D. Eastlake",
TITLE="Electronic Commerce Modeling Language {(ECML):} Version 2 Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3505,
PAGES=8,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT="This document lists the design principles, scope, and requirements for
the Electronic Commerce Modeling Language (ECML) version 2
specification.  It includes requirements as they relate to Extensible
Markup Language (XML) syntax, data model, format, and payment
processing.

This document is a product of the Internet Open Trading Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3505.txt"
}

@TECHREPORT{rfc3506,
AUTHOR="Kikuo Fujimura and D. Eastlake",
TITLE="Requirements and Design for Voucher Trading System {(VTS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3506,
PAGES=15,
DAYS=15,
MONTH=mar,
YEAR=2003,
ABSTRACT={Crediting loyalty points and collecting digital coupons or gift
certificates are common functions in purchasing and trading
transactions.  These activities can be generalized using the concept
of a {"}voucher{"}, which is a digital representation of the right to
claim goods or services.  This document presents a Voucher Trading
System (VTS) that circulates vouchers securely and its terminology;
it lists design principles and requirements for VTS and the Generic
Voucher Language (GVL), with which diverse types of vouchers can be
described.

This document is a product of the Internet Open Trading Protocol
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3506.txt"
}

@TECHREPORT{rfc3507,
AUTHOR="J. Elson and Alberto Eduardo Cerpa",
TITLE="Internet Content Adaptation Protocol {(ICAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3507,
PAGES=49,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT={ICAP, the Internet Content Adaption Protocol, is a protocol aimed
at providing simple object-based content vectoring for HTTP
services.  ICAP is, in essence, a lightweight protocol for
executing a {"}remote procedure call{"} on HTTP messages.  It allows ICAP
clients to pass HTTP messages to ICAP servers for some sort of
transformation or other processing ({"}adaptation{"}).  The server
executes its transformation service on messages and sends back
responses to the client, usually with modified messages.  Typically,
the adapted messages are either HTTP requests or HTTP responses.},
URL="http://www.rfc-editor.org/rfc/rfc3507.txt"
}

@TECHREPORT{rfc3508,
AUTHOR="O. Levin",
TITLE="{H.323} Uniform Resource Locator {(URL)} Scheme Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3508,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="ITU-T Recommendation H.323 version 4 introduced an H.323-specific
Uniform Resource Locator (URL).  This document reproduces the H323-URL
definition found in H.323, and is published as an RFC for ease of
access and registration with the Internet Assigned Numbers Authority
(IANA).",
URL="http://www.rfc-editor.org/rfc/rfc3508.txt"
}

@TECHREPORT{rfc3509,
AUTHOR="A. Zinin and A. Lindem and Donald Yeung",
TITLE="Alternative Implementations of {OSPF} Area Border Routers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3509,
PAGES=12,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="Open Shortest Path First (OSPF) is a link-state intra-domain routing
protocol used for routing in IP networks.  Though the definition of
the Area Border Router (ABR) in the OSPF specification does not
require a router with multiple attached areas to have a backbone
connection, it is actually necessary to provide successful routing to
the inter-area and external destinations.  If this requirement is not
met, all traffic destined for the areas not connected to such an ABR
or out of the OSPF domain, is dropped.  This document describes
alternative ABR behaviors implemented in Cisco and IBM routers.

This document is a product of the Open Shortest Path First IGP Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3509.txt"
}

@TECHREPORT{rfc3510,
AUTHOR="R. Herriot and I. McDonald",
TITLE="Internet Printing Protocol/1.1: {IPP} {URL} Scheme",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3510,
PAGES=16,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT={This memo defines the {"}ipp{"} URL (Uniform Resource Locator) scheme.
This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by
expanding and clarifying Section 5, {"}IPP URL Scheme{"}, of RFC 2910.  An
{"}ipp{"} URL is used to specify the network location of a print service
that supports the IPP Protocol (RFC 2910), or of a network resource
(for example, a print job) managed by such a print service.

This document is a product of the Internet Printing Protocol Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3510.txt"
}

@TECHREPORT{rfc3511,
AUTHOR="B. Hickman and D. Newman and S. Tadjudin and T. P. Martin",
TITLE="Benchmarking Methodology for Firewall Performance",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3511,
PAGES=34,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="This document discusses and defines a number of tests that may be used
to describe the performance characteristics of firewalls.  In addition
to defining the tests, this document also describes specific formats
for reporting the results of the tests.

This document is a product of the Benchmarking Methodology Working
Group IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3511.txt"
}

@TECHREPORT{rfc3512,
AUTHOR="M. MacFaden and D. Partain and J. Saperia and W. Tackabury",
TITLE="Configuring Networks and Devices with Simple Network Management Protocol
{(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3512,
PAGES=83,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="This document is written for readers interested in the Internet
Standard Management Framework and its protocol, the Simple Network
Management Protocol (SNMP).  In particular, it offers guidance in the
effective use of SNMP for configuration management.  This information
is relevant to vendors that build network elements, management
application developers, and those that acquire and deploy this
technology in their networks.

This document is a product of the Configuration Management with SNMP
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3512.txt"
}

@TECHREPORT{rfc3513,
AUTHOR="Robert Hinden and S. E. Deering",
TITLE="Internet Protocol Version 6 {(IPv6)} Addressing Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3513,
PAGES=25,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="This specification defines the addressing architecture of the IP
Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
model, text representations of IPv6 addresses, definition of IPv6
unicast addresses, anycast addresses, and multicast addresses, and an
IPv6 node's required addresses.

This document is a product of the IP Version 6 Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3513.txt"
}

@TECHREPORT{rfc3515,
AUTHOR="R. Sparks",
TITLE="The Session Initiation Protocol {(SIP)} Refer Method",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3515,
PAGES=23,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="This document defines the REFER method.  This Session Initiation
Protocol (SIP) extension requests that the recipient REFER to a
resource provided in the request.  It provides a mechanism allowing
the party sending the REFER to be notified of the outcome of the
referenced request.  This can be used to enable many applications,
including call transfer.

In addition to the REFER method, this document defines the the refer
event package and the Refer-To request header.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3515.txt"
}

@TECHREPORT{rfc3516,
AUTHOR="L. Nerenberg",
TITLE="{IMAP4} Binary Content Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3516,
PAGES=8,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="This memo defines the Binary extension to the Internet Message Access
Protocol (IMAP4).  It provides a mechanism for IMAP4
clients and servers to exchange message body data without using a MIME
content-transfer-encoding.",
URL="http://www.rfc-editor.org/rfc/rfc3516.txt"
}

@TECHREPORT{rfc3517,
AUTHOR="E. Blanton and M. Allman and K. Fall and L. Wang",
TITLE="A Conservative Selective Acknowledgment {(SACK)-based} Loss Recovery
Algorithm for {TCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3517,
MONTH=apr,
YEAR=2003,
ABSTRACT="This document presents a conservative loss recovery algorithm for TCP that
is based on the use of the selective acknowledgment (SACK) TCP option. The
algorithm presented in this document conforms to the spirit of the current
congestion control specification (RFC 2581), but allows TCP senders to
recover more effectively when multiple segments are lost from a single
flight of data.",
URL="http://www.rfc-editor.org/rfc/rfc3517.txt"
}

@TECHREPORT{rfc3518,
AUTHOR="M. Higashiyama and Fred andy Baker and Tie Liao",
TITLE="{Point-to-Point} Protocol {(PPP)} Bridging Control Protocol {(BCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3518,
PAGES=40,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.  PPP
defines an extensible Link Control Protocol (LCP) and proposes a
family of Network Control Protocols (NCP) for establishing and
configuring different network-layer protocols.

This document defines the NCP for establishing and configuring Remote
Bridging for PPP links.

This document obsoletes RFC 2878, which was based on the IEEE
802.1D-1993 MAC Bridge.  This document extends that specification
by improving support for bridge control packets.

This document is a product of the Point-to-Point Protocol Extensions
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3518.txt"
}

@TECHREPORT{rfc3519,
AUTHOR="H. Levkowetz and S. Vaarala",
TITLE="Mobile {IP} Traversal of Network Address Translation {(NAT)} Devices",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3519,
MONTH=apr,
YEAR=2003,
ABSTRACT="Mobile IP's datagram tunnelling is incompatible with Network Address
Translation (NAT). This document presents extensions to the Mobile IP
protocol and a tunnelling method which permits mobile nodes using Mobile IP
to operate in private address networks which are separated from the public
internet by NAT devices. The NAT traversal is based on using the Mobile IP
Home Agent UDP port for encapsulated data traffic.",
URL="http://www.rfc-editor.org/rfc/rfc3519.txt"
}

@TECHREPORT{rfc3520,
AUTHOR="L-n. Hamer and B. Gage and B. Kosinski and H. Shieh",
TITLE="Session Authorization Policy Element",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3520,
PAGES=30,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="This document describes the representation of a session
authorization policy element for supporting policy-based per-session
authorization and admission control.  The goal of session
authorization is to allow the exchange of information between
network elements in order to authorize the use of resources for a
service and to co-ordinate actions between the signaling and
transport planes.  This document describes how a process on a system
authorizes the reservation of resources by a host and then provides
that host with a session authorization policy element which can be
inserted into a resource reservation protocol (e.g., the Resource
ReSerVation Protocol (RSVP) PATH message) to facilitate proper and
secure reservation of those resources within the network.  We describe
the encoding of session authorization information as a policy element
conforming to the format of a Policy Data object (RFC 2750) and
provide details relating to operations, processing rules and error
scenarios.

This document is a product of the Resource Allocation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3520.txt"
}

@TECHREPORT{rfc3521,
AUTHOR="L-n. Hamer and B. Gage and H. Shieh",
TITLE="Framework for Session Set-up with Media Authorization",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3521,
PAGES=25,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="Establishing multimedia streams must take into account requirements
for end-to-end QoS, authorization of network resource usage and
accurate accounting for resources used.  During session set up,
policies may be enforced to ensure that the media streams being
requested lie within the bounds of the service profile established
for the requesting host.  Similarly, when a host requests resources
to provide a certain QoS for a packet flow, policies may be enforced
to ensure that the required resources lie within the bounds of the
resource profile established for the requesting host.

To prevent fraud and to ensure accurate billing, this document
describes various scenarios and mechanisms that provide the linkage
required to verify that the resources being used to provide a
requested QoS are in-line with the media streams requested (and
authorized) for the session.

This document is a product of the Resource Allocation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3521.txt"
}

@TECHREPORT{rfc3522,
AUTHOR="R. Ludwig and M. Meyer",
TITLE="The Eifel Detection Algorithm for {TCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3522,
MONTH=apr,
YEAR=2003,
ABSTRACT="The Eifel detection algorithm allows a TCP sender to detect a posteriori
whether it has entered loss recovery unnecessarily. It requires that the
TCP Timestamps option defined in RFC 1323 be enabled for a connection. The
Eifel detection algorithm makes use of the fact that the TCP Timestamps
option eliminates the retransmission ambiguity in TCP. Based on the
timestamp of the first acceptable ACK that arrives during loss recovery, it
decides whether loss recovery was entered unnecessarily. The Eifel
detection algorithm provides a basis for future TCP enhancements. This
includes response algorithms to back out of loss recovery by restoring a
TCP sender's congestion control state.",
URL="http://www.rfc-editor.org/rfc/rfc3522.txt"
}

@TECHREPORT{rfc3523,
AUTHOR="J. Polk",
TITLE="Internet Emergency Preparedness {(IEPREP)} Telephony Topology Terminology",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3523,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="This document defines the topology naming conventions that are to be
used in reference to Internet Emergency Preparedness (IEPREP) phone
calls.  These naming conventions should be used to focus the IEPREP
Working Group during discussions and when writing requirements, gap
analysis and other solutions documents.

This document is a product of the Internet Emergency Preparedness
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3523.txt"
}

@TECHREPORT{rfc3524,
AUTHOR="Gonzalo  Camarillo and A. Monrad",
TITLE="Mapping of Media Streams to Resource Reservation Flows",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3524,
PAGES=6,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT={This document defines an extension to the Session Description Protocol
(SDP) grouping framework.  It allows requesting a group of media
streams to be mapped into a single resource reservation flow.  The SDP
syntax needed is defined, as well as a new {"}semantics{"} attribute
called Single Reservation Flow (SRF).

This document is a product of the Multiparty Multimedia Session
Control Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3524.txt"
}

@TECHREPORT{rfc3525,
AUTHOR="C. Groves and M. Pantaleo and Thomas Anderson and Tracy M. Taylor and  
Editors",
TITLE="Gateway Control Protocol Version 1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3525,
PAGES=213,
DAYS=15,
MONTH=jun,
YEAR=2003,
ABSTRACT="This document defines the protocol used between elements of a
physically decomposed multimedia gateway, i.e., a Media Gateway and a
Media Gateway Controller.  The protocol presented in this document
meets the requirements for a media gateway control protocol as
presented in RFC 2805.

This document replaces RFC 3015.  It is the result of
continued cooperation between the IETF Megaco Working Group and ITU-T
Study Group 16.  It incorporates the original text of RFC 3015,
modified by corrections and clarifications discussed on the Megaco

E-mail list and incorporated into the Study Group 16 Implementor's
Guide for Recommendation H.248.  The present version of this document
underwent  ITU-T Last Call as Recommendation H.248 Amendment 1.
Because of ITU-T renumbering, it was published by the ITU-T as
Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.

Users of this specification are advised to consult the H.248
Sub-series Implementors' Guide at
http://www.itu.int/itudoc/itu-t/com16/implgd for additional
corrections and clarifications.

This document is a product of the Media Gateway Control Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3525.txt"
}

@TECHREPORT{rfc3526,
AUTHOR="T. Kivinen and Markku Kojo",
TITLE="More Modular Exponential {(MODP)} {Diffie-Hellman} groups for Internet Key
Exchange {(IKE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3526,
PAGES=10,
DAYS=15,
MONTH=may,
YEAR=2003,
ABSTRACT="This document defines new Modular Exponential (MODP) Groups for the
Internet Key Exchange (IKE) protocol.  It documents the well known and
used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144,
and 8192 bit Diffie-Hellman groups numbered starting at 14.  The
selection of the primes for theses groups follows the criteria
established by Richard Schroeppel.

This document is a product of the IP Security Protocol Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3526.txt"
}

@TECHREPORT{rfc3527,
AUTHOR="K. Kinnear and Mark Stapp and Ralph Johnson and J. Kumarasamy",
TITLE="Link Selection sub-option for the Relay Agent Information Option for
{DHCPv4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3527,
PAGES=9,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="This document describes the link selection sub-option of the
relay-agent-information option for the Dynamic Host Configuration
Protocol (DHCPv4).  The giaddr specifies an IP address which
determines both a subnet, and thereby a link on which a Dynamic Host
Configuration Protocol (DHCP) client resides as well as an IP address
that can be used to communicate with the relay agent.  The
subnet-selection option allows the functions of the giaddr to be split
so that when one entity is performing as a DHCP proxy, it can specify
the subnet/link from which to allocate an IP address, which is
different from the IP address with which it desires to communicate
with the DHCP server.  Analogous situations exist where the relay
agent needs to specify the subnet/link on which a DHCP client resides,
which is different from an IP address that can be used to communicate
with the relay agent.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3527.txt"
}

@TECHREPORT{rfc3528,
AUTHOR="Weibin Zhao and Henning Schulzrinne and Erik Guttman",
TITLE="Mesh-enhanced Service Location Protocol {(mSLP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3528,
MONTH=apr,
YEAR=2003,
URL="http://www.rfc-editor.org/rfc/rfc3528.txt"
}

@TECHREPORT{rfc3529,
AUTHOR="W. Harold",
TITLE="Using Extensible Markup {Language-Remote} Procedure Calling {(XML-RPC)} in
Blocks Extensible Exchange Protocol {(BEEP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3529,
MONTH=apr,
YEAR=2003,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc3529.txt"
}

@TECHREPORT{rfc3530,
AUTHOR="S. Shepler and Brent Callaghan and David Peter Robinson and R. Thurlow and
C. Beame and M. Eisler and D. Noveck",
TITLE="Network File System {(NFS)} version 4 Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3530,
PAGES=275,
DAYS=15,
MONTH=apr,
YEAR=2003,
ABSTRACT="The Network File System (NFS) version 4 is a distributed filesystem
protocol which owes heritage to NFS protocol version 2, RFC 1094, and
version 3, RFC 1813.  Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support
for file locking and the mount protocol.  In addition, support for
strong security (and its negotiation), compound operations, client
caching, and internationalization have been added.  Of course,
attention has been applied to making NFS version 4 operate well in an
Internet environment.

This document replaces RFC 3010 as the definition of the NFS version 4
protocol.

This document is a product of the Network File System Version 4
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3530.txt"
}

@TECHREPORT{rfc3531,
AUTHOR="M. Blanchet",
TITLE="A Flexible Method for Managing the Assignment of Bits of an {IPv6} Address
Block",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3531,
MONTH=apr,
YEAR=2003,
ABSTRACT="This document proposes a method to manage the assignment of bits of an IPv6
address block or range. When an organisation needs to make an address plan
for its subnets or when an ISP needs to make an address plan for its
customers, this method enables the organisation to postpone the final
decision on the number of bits to partition in the address space they have.
It does it by keeping the bits around the borders of the partition to be
free as long as possible. This scheme is applicable to any bits addressing
scheme using bits with partitions in the space, but its first intended use
is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6
assignments.",
URL="http://www.rfc-editor.org/rfc/rfc3531.txt"
}

@TECHREPORT{rfc3532,
AUTHOR="Thomas Anderson and J. Buerkle",
TITLE="Requirements for the Dynamic Partitioning of Switching Elements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3532,
PAGES=11,
DAYS=15,
MONTH=may,
YEAR=2003,
ABSTRACT="This document identifies a set of requirements for the mechanisms
used to dynamically reallocate the resources of a switching element
(e.g., an ATM switch) to its partitions.  These requirements are
particularly critical in the case of an operator creating a switch
partition and then leasing control of that partition to a third
party.

This document is a product of the General Switch Management Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3532.txt"
}

@TECHREPORT{rfc3536,
AUTHOR="Paul Hoffman",
TITLE="Terminology Used in Internationalization in the {IETF}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3536,
PAGES=30,
DAYS=15,
MONTH=may,
YEAR=2003,
ABSTRACT="This document provides a glossary of terms used in the IETF when
discussing internationalization.  The purpose is to help frame
discussions of internationalization in the various areas of the IETF
and to help introduce the main concepts to IETF participants.",
URL="http://www.rfc-editor.org/rfc/rfc3536.txt"
}

@TECHREPORT{rfc3537,
AUTHOR="J. Schaad and R. Housley",
TITLE="Wrapping a Hashed Message Authentication Code {(HMAC)} key with a
{Triple-Data} Encryption Standard {(DES)} Key or an Advanced Encryption
Standard {(AES)} Key",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3537,
PAGES=9,
DAYS=15,
MONTH=may,
YEAR=2003,
ABSTRACT="This document defines two methods for wrapping an HMAC (Hashed Message
Authentication Code) key.  The first method defined uses a Triple DES
(Data Encryption Standard) key to encrypt the HMAC key.  The second
method defined uses an AES (Advanced Encryption Standard) key to
encrypt the HMAC key.  One place that such an algorithm is used is for
the Authenticated Data type in CMS (Cryptographic Message Syntax).

This document is a product of the S/MIME Mail Security Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3537.txt"
}

@TECHREPORT{rfc3538,
AUTHOR="Y. Kawatsura",
TITLE="Secure Electronic Transaction {(SET)} Supplement for the v1.0 Internet Open
Trading Protocol {(IOTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3538,
MONTH=jun,
YEAR=2003,
ABSTRACT="This document describes detailed Input/Output parameters for the Internet
Open Trading Protocol (IOTP) Payment Application Programming Interface
(API). It also describes procedures in the Payment Bridge for the use of
SET (SET Secure Electronic Transaction) as the payment protocol within
Version 1.0 of the IOTP.",
URL="http://www.rfc-editor.org/rfc/rfc3538.txt"
}

@TECHREPORT{rfc3539,
AUTHOR="Bernard D Aboba and Jonathan Wood",
TITLE="Authentication, Authorization and Accounting {(AAA)} Transport Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3539,
PAGES=41,
DAYS=15,
MONTH=jun,
YEAR=2003,
ABSTRACT="This document discusses transport issues that arise within protocols
for Authentication, Authorization and Accounting (AAA).  It also
provides recommendations on the use of transport by AAA protocols.
This includes usage of standards-track RFCs as well as experimental
proposals.

This document is a product of the Authentication, Authorization and
Accounting Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3539.txt"
}

@TECHREPORT{rfc3540,
AUTHOR="N. Spring and D. Wetherall and D. Ely",
TITLE="Robust Explicit Congestion Notification {(ECN)} Signaling with Nonces",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3540,
MONTH=jun,
YEAR=2003,
ABSTRACT="This note describes the Explicit Congestion Notification (ECN)-nonce, an
optional addition to ECN that protects against accidental or malicious
concealment of marked packets from the TCP sender. It improves the
robustness of congestion control by preventing receivers from exploiting
ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the
two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP
header, and requires a flag in the TCP header. It is computationally
efficient for both routers and hosts.",
URL="http://www.rfc-editor.org/rfc/rfc3540.txt"
}

@TECHREPORT{rfc3541,
AUTHOR="A. B. Walsh",
TITLE="A Uniform Resource Name {(URN)} Namespace for the {Web3D} Consortium
{(Web3D)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3541,
PAGES=6,
DAYS=15,
MONTH=may,
YEAR=2003,
ABSTRACT="This document describes a Uniform Resource Name (URN) namespace for
the Web3D Consortium (Web3D) for naming persistent resources
such as technical documents and specifications, Virtual Reality
Modeling Language (VRML) and Extensible 3D (X3D) files and resources,
Extensible Markup Language (XML) Document Type Definitions (DTDs),
XML Schemas, namespaces, style sheets, media assets, and
other resources produced or managed by Web3D.",
URL="http://www.rfc-editor.org/rfc/rfc3541.txt"
}

@TECHREPORT{rfc3542,
AUTHOR="W. Richard Stevens and M R Thomas and Erik Nordmark and Tatsuya Jinmei",
TITLE="Advanced Sockets Application Protocol Interface {(API)} for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3542,
PAGES=77,
DAYS=15,
MONTH=may,
YEAR=2003,
ABSTRACT={This document provides sockets Application Program Interface (API) to
support {"}advanced{"} IPv6 applications, as a supplement to a separate
specification, RFC 3493.  The expected applications include Ping,
Traceroute, routing daemons and the like, which typically use raw
sockets to access IPv6 or ICMPv6 header fields.  This document
proposes some portable interfaces for applications that use raw
sockets under IPv6.  There are other features of IPv6 that some
applications will need to access: interface identification (specifying
the outgoing interface and determining the incoming interface), IPv6
extension headers, and path Maximum Transmission Unit (MTU)
information.  This document provides API access to these features too.
Additionally, some extended interfaces to libraries for the {"}r{"}
commands are defined.  The extension will provide better backward
compatibility to existing implementations that are not IPv6-capable.

This document is a product of the IP Version 6 Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3542.txt"
}

@TECHREPORT{rfc3543,
AUTHOR="S. Glass and Madhavi Chandra",
TITLE="Registration Revocation in Mobile {IPv4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3543,
PAGES=33,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT="This document defines a Mobile IPv4 Registration Revocation
mechanism whereby a mobility agent involved in providing Mobile IP
services to a mobile node can notify the other mobility agent
providing Mobile IP services to the same mobile node of the
termination of this registration.  The mechanism is also usable by a
home agent to notify a co-located mobile node of the termination of
its binding as well.  Moreover, the mechanism provides for this
notification to be acknowledged.  A signaling mechanism already
defined by the Mobile IPv4 protocol is leveraged as a way to inform a
mobile node of the revocation of its binding.

This document is a product of the IP Routing for Wireless/Mobile Hosts
Working Group.",
URL="http://www.rfc-editor.org/rfc/rfc3543.txt"
}

@TECHREPORT{rfc3544,
AUTHOR="T. Koren and Stephen Casner and Carsten Bormann",
TITLE="{IP} Header Compression over {PPP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3544,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes an option for negotiating the use of header
compression on IP datagrams transmitted over the Point-to-Point
Protocol (RFC 1661).  It defines extensions to the PPP Control
Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472).  Header compression
may be applied to IPv4 and IPv6 datagrams in combination with TCP,
UDP and RTP transport protocols as specified in RFC 2507,
RFC 2508 and RFC 3545.",
URL="http://www.rfc-editor.org/rfc/rfc3544.txt"
}

@TECHREPORT{rfc3545,
AUTHOR="T. Koren and Stephen Casner and J. Geevarghese and B. Thompson and P. Ruddy",
TITLE="Enhanced Compressed {RTP} {(CRTP)} for Links with High Delay, Packet Loss
and Reordering",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3545,
PAGES=22,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes a header compression scheme for point to
point links with packet loss and long delays.  It is based on
Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP
header compression described in RFC 2508.  CRTP does not perform well
on such links: packet loss results in context corruption and due to
the long delay, many more packets are discarded before the context
is repaired.  To correct the behavior of CRTP over such links, a few
extensions to the protocol are specified here.  The extensions aim to
reduce context corruption by changing the way the compressor updates
the context at the decompressor: updates are repeated and include
updates to full and differential context parameters.  With these
extensions, CRTP performs well over links with packet loss, packet
reordering and long delays.

This document is a product of the Audio Video Transport Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3545.txt"
}

@TECHREPORT{rfc3546,
AUTHOR="S. Blake-Wilson and M. Nystrom and D. Hopwood and J. Mikkelsen and Thomas
Wright",
TITLE="Transport Layer Security {(TLS)} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3546,
PAGES=29,
DAYS=15,
MONTH=jun,
YEAR=2003,
ABSTRACT="This document describes extensions that may be used to add
functionality to Transport Layer Security (TLS).  It provides both
generic extension mechanisms for the TLS handshake client and server
hellos, and specific extensions using these generic mechanisms.

The extensions may be used by TLS clients and servers.  The extensions
are backwards compatible - communication is possible between TLS 1.0
clients that support the extensions and TLS 1.0 servers that do not
support the extensions, and vice versa.

This document is a product of the Transport Layer Security Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3546.txt"
}

@TECHREPORT{rfc3547,
AUTHOR="Mark Baugher and Bernd Xaver Weis and Thomas Hardjono and Hugh Harney",
TITLE="The Group Domain of Interpretation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3547,
PAGES=48,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management to support secure group communications.  The
GDOI manages group security associations, which are used by IPSEC and
potentially other data security protocols running at the IP or
application layers.  These security associations protect one or more
key-encrypting keys, traffic-encrypting keys, or data shared by group
members.

This document is a product of the Multicast Security Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3547.txt"
}

@TECHREPORT{rfc3548,
AUTHOR="S. Josefsson and I. W. Ed.",
TITLE="The Base16, Base32, and Base64 Data Encodings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3548,
PAGES=13,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes the commonly used base 64, base 32, and base
16 encoding schemes.  It also discusses the use of line-feeds in
encoded data, use of padding in encoded data, use of non-alphabet
characters in encoded data, and use of different encoding alphabets.",
URL="http://www.rfc-editor.org/rfc/rfc3548.txt"
}

@TECHREPORT{rfc3549,
AUTHOR="Jamal Hadi Salim and Hormuzd M. Khosravi and A. Kleen and Alexander
Kuznetsov",
TITLE="Linux Netlink as an {IP} Services Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3549,
PAGES=33,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes Linux Netlink, which is used in Linux both
as an intra-kernel messaging system as well as between kernel and
user space.  The focus of this document is to describe Netlink's
functionality as a protocol between a Forwarding Engine Component
(FEC) and a Control Plane Component (CPC), the two components that
define an IP service.  As a result of this focus, this document
ignores other uses of Netlink, including its use as a intra-kernel
messaging system, as an inter-process communication scheme (IPC), or
as a configuration tool for other non-networking or non-IP network
services (such as decnet, etc.).

This document is intended as informational in the context of prior art
for the ForCES IETF working group.

This document is a product of the Forwarding and Control Element
Separation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3549.txt"
}

@TECHREPORT{rfc3550,
AUTHOR="Henning Schulzrinne and Stephen Casner and Ron Frederick and Van Jacobson",
TITLE="{RTP:} A Transport Protocol for {Real-Time} Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3550,
PAGES=104,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="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.

Most of the text in this memorandum is identical to RFC 1889 which it
obsoletes.  There are no changes in the packet formats on the wire,
only changes to the rules and algorithms governing how the protocol
is used.  The biggest change is an enhancement to the scalable timer
algorithm for calculating when to send RTCP packets in order to
minimize transmission in excess of the intended rate when many
participants join a session simultaneously.

This document is a product of the Audio/Video Tranposrt Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3550.txt"
}

@TECHREPORT{rfc3551,
AUTHOR="Henning Schulzrinne and Stephen Casner",
TITLE="{RTP} Profile for Audio and Video Conferences with Minimal Control",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3551,
PAGES=44,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT={This document describes a profile called {"}RTP/AVP{"} for the use of the
real-time transport protocol (RTP), version 2, and the associated
control protocol, RTCP, within audio and video multiparticipant
conferences with minimal control.  It provides interpretations of
generic fields within the RTP specification suitable for audio and
video conferences.  In particular, this document defines a set of
default mappings from payload type numbers to encodings.

This document also describes how audio and video data may be carried
within RTP.  It defines a set of standard encodings and their names
when used within RTP.  The descriptions provide pointers to reference
implementations and the detailed standards.  This document is meant
as an aid for implementors of audio, video and other real-time
multimedia applications.

This memorandum obsoletes RFC 1890.  It is mostly backwards-compatible
except for functions removed because two interoperable implementations
were not found.  The additions to RFC 1890 codify existing practice in
the use of payload formats under this profile and include new payload
formats defined since RFC 1890 was published.

This document is a product of the Audio/Video Transport Working Group
of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3551.txt"
}

@TECHREPORT{rfc3554,
AUTHOR="Steven M Bellovin and John Ioannidis and Angelos D. Keromytis and Randall
Stewart",
TITLE="On the Use of Stream Control Transmission Protocol {(SCTP)} with {IPsec}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3554,
PAGES=9,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes functional requirements for IPsec (RFC 2401)
and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in
securing SCTP (RFC 2960) traffic.

This document is a product of the IP Security Protocol Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3554.txt"
}

@TECHREPORT{rfc3555,
AUTHOR="Stephen Casner and Philipp Hoschka",
TITLE="{MIME} Type Registration of {RTP} Payload Formats",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3555,
PAGES=45,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document defines the procedure to register RTP Payload Formats
as audio, video or other MIME subtype names.  This is useful in a
text-based format or control protocol to identify the type of an
RTP transmission.  This document also registers all the RTP payload
formats defined in the RTP Profile for Audio and Video Conferences
as MIME subtypes.  Some of these may also be used for transfer
modes other than RTP.

This document is a product of the Audio/Video Transport Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3555.txt"
}

@TECHREPORT{rfc3556,
AUTHOR="Stephen Casner",
TITLE="Session Description Protocol {(SDP)} Bandwidth Modifiers for {RTP} Control
Protocol {(RTCP)} Bandwidth",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3556,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document defines an extension to the Session Description Protocol
(SDP) to specify two additional modifiers for the bandwidth attribute.
These modifiers may be used to specify the bandwidth allowed for RTP
Control Protocol (RTCP) packets in a Real-time Transport Protocol
(RTP) session.

This document is a product of the Audio/Video Transport Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3556.txt"
}

@TECHREPORT{rfc3557,
AUTHOR="Qian Xie and I. W. Ed.",
TITLE="{RTP} Payload Format for European Telecommunications Standards Institute
{(ETSI)} European Standard {ES} 201 108 Distributed Speech Recognition
Encoding",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3557,
PAGES=15,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document specifies an RTP payload format for encapsulating
European Telecommunications Standards Institute (ETSI) European
Standard (ES) 201 108 front-end signal processing feature streams
for distributed speech recognition (DSR) systems.

This document is a product of the Audio/Video Transport Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3557.txt"
}

@TECHREPORT{rfc3558,
AUTHOR="Aihui Li",
TITLE="{RTP} Payload Format for Enhanced Variable Rate Codecs {(EVRC)} and
Selectable Mode Vocoders {(SMV)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3558,
PAGES=23,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes the RTP payload format for Enhanced Variable
Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV)
Speech.  Two sub-formats are specified for different application
scenarios.  A bundled/interleaved format is included to reduce the
effect of packet loss on speech quality and amortize the overhead of
the RTP header over more than one speech frame.  A non-bundled format
is also supported for conversational applications.

This document is a product of the Audio/Video Transport Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3558.txt"
}

@TECHREPORT{rfc3559,
AUTHOR="Dave Thaler",
TITLE="Multicast Address Allocation {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3559,
PAGES=37,
DAYS=15,
MONTH=jun,
YEAR=2003,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
multicast address allocation.

This document is a product of the Multicast Address Allocation Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3559.txt"
}

@TECHREPORT{rfc3560,
AUTHOR="R. Housley",
TITLE="Use of the {RSAES-OAEP} Key Transport Algorithm in Cryptographic Message
Syntax {(CMS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3560,
PAGES=18,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes the conventions for using the RSAES-OAEP key
transport algorithm with the Cryptographic Message Syntax (CMS).  The
CMS specifies the enveloped-data content type, which consists of an
encrypted content and encrypted content-encryption keys for one or
more recipients.  The RSAES-OAEP key transport algorithm can be used
to encrypt content-encryption keys for intended recipients.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3560.txt"
}

@TECHREPORT{rfc3561,
AUTHOR="C. E. Perkins and E. Belding-Royer and S. Das",
TITLE="Ad hoc {On-Demand} Distance Vector {(AODV)} Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3561,
MONTH=jul,
YEAR=2003,
ABSTRACT="The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended
for use by mobile nodes in an ad hoc network. It offers quick adaptation to
dynamic link conditions, low processing and memory overhead, low network
utilization, and determines unicast routes to destinations within the ad
hoc network. It uses destination sequence numbers to ensure loop freedom at
all times (even in the face of anomalous delivery of routing control
messages), avoiding problems (such as counting to infinity) associated with
classical distance vector protocols.",
URL="http://www.rfc-editor.org/rfc/rfc3561.txt"
}

@TECHREPORT{rfc3562,
AUTHOR="M. Leech",
TITLE="Key Management Considerations for the {TCP} {MD5} Signature Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3562,
PAGES=7,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="The TCP MD5 Signature Option (RFC 2385), used
predominantly by BGP, has seen significant deployment in critical
areas of Internet infrastructure.  The security of this option relies
heavily on the quality of the keying material used to compute the MD5
signature.  This document addresses the security requirements of that
keying material.

This document is a product of the Inter-Domain Routing Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3562.txt"
}

@TECHREPORT{rfc3563,
AUTHOR="A. Zinin",
TITLE="Cooperative Agreement Between the {ISOC/IETF} and {ISO/IEC} Joint Technical
Committee 1/Sub Committee 6 {(JTC1/SC6)} on {IS-IS} Routing Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3563,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document contains the text of the agreement signed between
ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of
the IS-IS routing protocol.  The agreement includes definitions of the
related work scopes for the two organizations, request for creation
and maintenance of an IS-IS registry by IANA, as well as
collaboration guidelines.",
URL="http://www.rfc-editor.org/rfc/rfc3563.txt"
}

@TECHREPORT{rfc3564,
AUTHOR="F. Le Faucheur and Wai Sum Lai",
TITLE="Requirements for Support of Differentiated Services-aware {MPLS} Traffic
Engineering",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3564,
PAGES=22,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document presents Service Provider requirements for support of
Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering
(DS-TE).

Its objective is to provide guidance for the definition, selection
and specification of a technical solution addressing these
requirements.  Specification for this solution itself is outside the
scope of this document.

A problem statement is first provided.  Then, the document describes
example applications scenarios identified by Service Providers where
existing MPLS Traffic Engineering mechanisms fall short and
Diff-Serv-aware Traffic Engineering can address the needs.  The
detailed requirements that need to be addressed by the technical
solution are also reviewed.  Finally, the document identifies the
evaluation criteria that should be considered for selection and
definition of the technical solution.

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3564.txt"
}

@TECHREPORT{rfc3565,
AUTHOR="J. Schaad",
TITLE="Use of the Advanced Encryption Standard {(AES)} Encryption Algorithm in
Cryptographic Message Syntax {(CMS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3565,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document specifies the conventions for using the Advanced
Encryption Standard (AES) algorithm for encryption with the
Cryptographic Message Syntax (CMS).

This document is a product of the S/MIME Mail Security Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3565.txt"
}

@TECHREPORT{rfc3566,
AUTHOR="S. Frankel and H. G. Herbert",
TITLE="The {AES-XCBC-MAC-96} Algorithm and Its Use With {IPsec}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3566,
PAGES=11,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="A Message Authentication Code (MAC) is a key-dependent one way hash
function.  One popular way to construct a MAC algorithm is to use a
block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode
of operation.  The classic CBC-MAC algorithm, while secure for
messages of a pre-selected fixed length, has been shown to be
insecure across messages of varying lengths such as the type found in
typical IP datagrams.  This memo specifies the use of AES in CBC mode
with a set of extensions to overcome this limitation.  This new
algorithm is named AES-XCBC-MAC-96.

This document is a product of the IPsec Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3566.txt"
}

@TECHREPORT{rfc3567,
AUTHOR="Tao Li and R. Atkinson",
TITLE="Intermediate System to Intermediate System {(IS-IS)} Cryptographic
Authentication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3567,
PAGES=6,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes the authentication of Intermediate System to
Intermediate System (IS-IS) Protocol Data Units (PDUs) using the
Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5)
algorithm as found in RFC 2104.  IS-IS is specified in International
Standards Organization (ISO) 10589, with extensions to support
Internet Protocol version 4 (IPv4) described in RFC 1195.  The base
specification includes an authentication mechanism that allows for
multiple authentication algorithms.  The base specification only
specifies the algorithm for cleartext passwords.

This document proposes an extension to that specification that
allows the use of the HMAC-MD5 authentication algorithm to be used in
conjunction with the existing authentication mechanisms.

This document is a product of IS-IS for IP Internets Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3567.txt"
}

@TECHREPORT{rfc3568,
AUTHOR="A. Barbir and Brad Cain and Raj Nair and Oliver Spatscheck",
TITLE="Known Content Network {(CN)} {Request-Routing} Mechanisms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3568,
PAGES=19,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document presents a summary of Request-Routing techniques that
are used to direct client requests to surrogates based on various 
policies and a possible set of metrics.  The document covers
techniques that were commonly used in the industry on or before
December 2000.  In this memo, the term Request-Routing represents
techniques that is commonly called content routing or content
redirection.  In principle, Request-Routing techniques can be
classified under: DNS Request-Routing, Transport-layer
Request-Routing, and Application-layer Request-Routing.

This document is a product of the Content Distribution Internetworking
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3568.txt"
}

@TECHREPORT{rfc3569,
AUTHOR="Santanu Bhattacharyya and I. W. Ed.",
TITLE="An Overview of {Source-Specific} Multicast {(SSM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3569,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="The purpose of this document is to provide an overview of 
Source-Specific Multicast (SSM) and issues related to its deployment.
It discusses how the SSM service model addresses the challenges faced
in inter-domain multicast deployment, changes needed to routing
protocols and applications to deploy SSM and interoperability issues
with current multicast service models.

This document is the product of the Source-Specific Multicast Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3569.txt"
}

@TECHREPORT{rfc3570,
AUTHOR="P. Rzewski and Mark Day and D. Gilletti",
TITLE="Content Internetworking {(CDI)} Scenarios",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3570,
PAGES=20,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="In describing content internetworking as a technology targeted for
use in production networks, it is useful to provide examples of the
sequence of events that may occur when two content networks decide
to interconnect.  The scenarios presented here seek to provide some
concrete examples of what content internetworking is, and also to
provide a basis for evaluating content internetworking proposals.

This document is a product of the Content Distribution Internetworking
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3570.txt"
}

@TECHREPORT{rfc3571,
AUTHOR="D. Rawlins and Amit Kulkarni and Kwong-wing Chan and M. Bokaemper and D.
Dutt",
TITLE="Framework Policy Information Base for Usage Feedback",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3571,
PAGES=35,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT="This document describes a portion of the Policy Information Base
(PIB) to control policy usage collection and reporting in a device.

The provisioning classes specified here allow a Policy Decision
Point (PDP) to select which policy objects should collect usage
information, what information should be collected and when it
should be reported.

This PIB requires the presence of other PIBs (defined elsewhere)
that provide the policy objects from which usage information is
collected.

This document is a product of the Resource Allocation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3571.txt"
}

@TECHREPORT{rfc3572,
AUTHOR="Takeshi Ogura and Masanori Maruyama and T. Yoshida",
TITLE="Internet Protocol Version 6 over {MAPOS} (Multiple Access Protocol Over
{SONET/SDH)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3572,
PAGES=14,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed
link-layer protocol that provides multiple access capability over a
Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH).

This document specifies the frame format for encapsulating an IPv6
datagram in a MAPOS frame.  It also specifies the method of forming
IPv6 interface identifiers, the method of detecting duplicate
addresses, and the format of the Source/Target Link-layer Addresses
option field used in IPv6 Neighbor Discovery messages.",
URL="http://www.rfc-editor.org/rfc/rfc3572.txt"
}

@TECHREPORT{rfc3573,
AUTHOR="I. Goyret",
TITLE="Signalling of {Modem-On-Hold} status in Layer 2 Tunneling Protocol {(L2TP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3573,
PAGES=13,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for
tunneling Point-to-Point Protocol (PPP) sessions.  It is common for
these PPP sessions to be established using modems connected over the
public switched telephone network.

One of the standards governing modem operation defines procedures
that enable a client modem to put the call on hold and later, re-
establish the modem link with minimal delay and without having to
redial.  While the modem call is on hold, the client phone line can
be used to place or receive other calls.

The L2TP base protocol does not provide any means to signal these
events from the L2TP Access Controller (LAC), where the modem is
physically connected, to the L2TP Network Server (LNS), where the PPP
session is handled.

This document describes a method to let the LNS know when a client
modem connected to a LAC has placed the call on hold.

This document is a product of the Layer Two Tunneling Protocol
Extensions Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3573.txt"
}

@TECHREPORT{rfc3574,
AUTHOR="Jonne Soininen and I. W. Ed.",
TITLE="Transition Scenarios for {3GPP} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3574,
PAGES=12,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT="This document describes different scenarios in Third Generation
Partnership Project (3GPP) defined packet network, i.e., General
Packet Radio Service (GPRS) that would need IP version 6 and IP
version 4 transition.  The focus of this document is on the scenarios
where the User Equipment (UE) connects to nodes in other networks,
e.g., in the Internet.  GPRS network internal transition scenarios,
i.e., between different GPRS elements in the network, are out of
scope.   The purpose of the document is to list the scenarios for
further discussion and study.

This document is a product of the IPv6 Operations Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3574.txt"
}

@TECHREPORT{rfc3575,
AUTHOR="Bernard D Aboba",
TITLE="{IANA} Considerations for {RADIUS} (Remote Authentication Dial In User
Service)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3575,
PAGES=8,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes the IANA considerations for the Remote
Authentication Dial In User Service (RADIUS).",
URL="http://www.rfc-editor.org/rfc/rfc3575.txt"
}

@TECHREPORT{rfc3576,
AUTHOR="M. Chiba and Gopal Dommety and M. Eklund and D. Mitton and Bernard D Aboba",
TITLE="Dynamic Authorization Extensions to Remote Authentication Dial In User
Service {(RADIUS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3576,
PAGES=30,
DAYS=15,
MONTH=jul,
YEAR=2003,
ABSTRACT="This document describes a currently deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, allowing
dynamic changes to a user session, as implemented by network access
server products.  This includes support for disconnecting users and
changing authorizations applicable to a user session.",
URL="http://www.rfc-editor.org/rfc/rfc3576.txt"
}

@TECHREPORT{rfc3577,
AUTHOR="Steven Waldbusser and Robert Cole and C. Kalbfleisch and D. Romascanu",
TITLE="Introduction to the Remote Monitoring {(RMON)} Family of {MIB} Modules",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3577,
PAGES=31,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT="The Remote Monitoring (RMON) Framework consists of a number of
interrelated documents.  This memo describes these documents and how
they relate to one another. 

This document is a product of the Remote Network Monitoring Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3577.txt"
}

@TECHREPORT{rfc3578,
AUTHOR="Gonzalo  Camarillo and A. B. Roach and James L. Peterson and Luke Ong",
TITLE="Mapping of Integrated Services Digital Network {(ISDN)} User Part {(ISUP)}
Overlap Signalling to the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3578,
PAGES=13,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT="This document describes a way to map Integrated Services Digital
Network User Part (ISUP) overlap signalling to Session Initiation
Protocol (SIP).  This mechanism might be implemented when using SIP in
an environment where part of the call involves interworking with the
Public Switched Telephone Network (PSTN).

This document is a product of the Session Initiation Proposal
Investigation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3578.txt"
}

@TECHREPORT{rfc3579,
AUTHOR="Bernard D Aboba and P. Calhoun",
TITLE="{RADIUS} (Remote Authentication Dial In User Service) Support For
Extensible Authentication Protocol {(EAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3579,
PAGES=46,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document defines Remote Authentication Dial In User Service
(RADIUS) support for the Extensible Authentication Protocol (EAP), an
authentication framework which supports multiple authentication
mechanisms.  In the proposed scheme, the Network Access Server (NAS)
forwards EAP packets to and from the RADIUS server, encapsulated
within EAP-Message attributes.  This has the advantage of allowing the
NAS to support any EAP authentication method, without the need for 
method-specific code, which resides on the RADIUS server.  While EAP
was originally developed for use with PPP, it is now also in use with
IEEE 802.",
URL="http://www.rfc-editor.org/rfc/rfc3579.txt"
}

@TECHREPORT{rfc3580,
AUTHOR="P. Congdon and Bernard D Aboba and A. J. Smith and G. Zorn and J. Roese",
TITLE="{IEEE} {802.1X} Remote Authentication Dial In User Service {(RADIUS)} Usage
Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3580,
PAGES=30,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document provides suggestions on Remote Authentication Dial In
User Service (RADIUS) usage by IEEE 802.1X Authenticators.  The
material in this document is also included within a non-normative
Appendix within the IEEE 802.1X specification, and is being presented
as an IETF RFC for informational purposes.",
URL="http://www.rfc-editor.org/rfc/rfc3580.txt"
}

@TECHREPORT{rfc3581,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne",
TITLE="An Extension to the Session Initiation Protocol {(SIP)} for Symmetric
Response Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3581,
PAGES=13,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT={The Session Initiation Protocol (SIP) operates over UDP and TCP, among
others.  When used with UDP, responses to requests are returned to the
source address the request came from, and to the port written into the
topmost Via header field value of the request.  This behavior is not
desirable in many cases, most notably, when the client is behind a
Network Address Translator (NAT).  This extension defines a new
parameter for the Via header field, called {"}rport{"}, that allows a
client to request that the server send the response back to the
source IP address and port from which the request originated.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3581.txt"
}

@TECHREPORT{rfc3582,
AUTHOR="J. Abley and B. Black and Vijay Gill",
TITLE="Goals for {IPv6} {Site-Multihoming} Architectures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3582,
PAGES=9,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT="This document outlines a set of goals for proposed new IPv6
site-multihoming architectures.  It is recognised that this set of
goals is ambitious and that some goals may conflict with others.  The
solution or solutions adopted may only be able to satisfy some of the
goals presented here.

This document is a product of the Site Multihoming in IPv6 Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3582.txt"
}

@TECHREPORT{rfc3583,
AUTHOR="Hemant Chaskar and I. W. Ed.",
TITLE="Requirements of a Quality of Service {(QoS)} Solution for Mobile {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3583,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="Mobile IP ensures correct routing of packets to a mobile node as the
mobile node changes its point of attachment to the
Internet.  However, it is also required to provide proper Quality of
Service (QoS) forwarding treatment to the mobile node's packet stream
at the intermediate nodes in the network, so that QoS-sensitive IP
services can be supported over Mobile IP.  This document describes
requirements for an IP QoS mechanism for its satisfactory operation
with Mobile IP.

This document is a product of the Next Steps in Signaling Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3583.txt"
}

@TECHREPORT{rfc3585,
AUTHOR="J. Jason and L. Rafalow and E. Vyncke",
TITLE="{IPsec} Configuration Policy Information Model",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3585,
PAGES=88,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT="This document presents an object-oriented information model of IP
Security (IPsec) policy designed to facilitate agreement about the
content and semantics of IPsec policy, and enable derivations of
task-specific representations of IPsec policy such as storage schema,
distribution representations, and policy specification languages used
to configure IPsec-enabled endpoints.  The information model
described in this document models the configuration parameters
defined by IPSec.  The information model also covers the parameters
found by the Internet Key Exchange protocol (IKE).  Other key
exchange protocols could easily be added to the information model by
a simple extension.  Further extensions can further be added easily
due to the object-oriented nature of the model.

This information model is based upon the core policy classes as
defined in the Policy Core Information Model (PCIM) and in the Policy
Core Information Model Extensions (PCIMe).

This document is a product of the IP Security Policy Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3585.txt"
}

@TECHREPORT{rfc3586,
AUTHOR="Matthew Blaze and Angelos D. Keromytis and M. F. Richardson and Luis
Sanchez",
TITLE="{IP} Security Policy {(IPSP)} Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3586,
PAGES=10,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT="This document describes the problem space and solution requirements
for developing an IP Security Policy (IPSP) configuration and
management framework.  The IPSP architecture provides a scalable,
decentralized framework for managing, discovering and negotiating the
host and network security policies that govern access, authorization,
authentication, confidentiality, data integrity, and other IP Security
properties.  This document highlights such architectural components
and presents their functional requirements.

This document is a product of the IP Security Policy Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3586.txt"
}

@TECHREPORT{rfc3587,
AUTHOR="Robert Hinden and S. E. Deering and Erik Nordmark",
TITLE="{IPv6} Global Unicast Address Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3587,
PAGES=5,
DAYS=15,
MONTH=aug,
YEAR=2003,
ABSTRACT={This document obsoletes RFC 2374, {"}An IPv6 Aggregatable Global Unicast
Address Format{"}.  It defined an IPv6 address allocation structure that
includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA).
This document makes RFC 2374 and the TLA/NLA structure historic.

This document is a product of the IP Version 6 Working Group of the
IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3587.txt"
}

@TECHREPORT{rfc3588,
AUTHOR="P. Calhoun and J. Loughney and Erik Guttman and G. Zorn and J. Arkko",
TITLE="Diameter Base Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3588,
PAGES=147,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="The Diameter base protocol is intended to provide an Authentication,
Authorization and Accounting (AAA) framework for applications such as
network access or IP mobility.  Diameter is also intended to work in
both local Authentication, Authorization \& Accounting and roaming
situations.  This document specifies the message format, transport,
error reporting, accounting and security services to be used by all
Diameter applications.  The Diameter base application needs to be
supported by all Diameter implementations.

This document is a product of the Authentication, Authorization and
Accounting Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3588.txt"
}

@TECHREPORT{rfc3589,
AUTHOR="J. Loughney",
TITLE="Diameter Command Codes for Third Generation Partnership Project {(3GPP)}
Release 5",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3589,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document describes the IANA's allocation of a block of Diameter
Command Codes for the Third Generation Partnership Project (3GPP)
Release 5.  This document does not pass judgment on the usage of these
command codes.  Further more, these command codes are for use for
Release 5.  For future releases, these codes cannot be reused, but
must be allocated according to the Diameter Base specification.",
URL="http://www.rfc-editor.org/rfc/rfc3589.txt"
}

@TECHREPORT{rfc3590,
AUTHOR="Brian Haberman",
TITLE="Source Address Selection for the Multicast Listener Discovery {(MLD)}
Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3590,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="It has come to light that there is an issue with the selection of a
suitable IPv6 source address for Multicast Listener Discovery
(MLD) messages when a node is performing stateless address
autoconfiguration.  This document is intended to clarify the rules on
selecting an IPv6 address to use for MLD messages.

This document is a product of the Multicast \& Anycast Group Membership
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3590.txt"
}

@TECHREPORT{rfc3591,
AUTHOR="H-k. Lam and M. Stewart and A. Huynh",
TITLE="Definitions of Managed Objects for the Optical Interface Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3591,
PAGES=173,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB)
for use with Simple Network Management Protocol (SNMP) in TCP/IP-based
internets.  In particular, it defines objects for managing Optical
Interfaces associated with WavelengthDivision Multiplexing systems or
characterized by the Optical Transport Network (OTN) in accordance
with the OTN architecture defined in ITU-T Recommendation G.872.

The MIB module defined in this memo can be used for performance
monitoring and/or configuration of such optical interface.

This document is a product of the AToM MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3591.txt"
}

@TECHREPORT{rfc3592,
AUTHOR="K. Tesink",
TITLE="Definitions of Managed Objects for the Synchronous Optical
{Network/Synchronous} Digital Hierarchy {(SONET/SDH)} Interface Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3592,
PAGES=73,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing Synchronous Optical
Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces.  This
document is a companion to the documents that define Managed Objects
for the DS1/E1/DS2/E2 and DS3/E3 Interface Types.

This memo replaces RFC 2558.  Changes relative to RFC 2558 are
summarized in the MIB module's REVISION clause.

This document is a product of the AToM MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3592.txt"
}

@TECHREPORT{rfc3593,
AUTHOR="K. Tesink and I. W. Ed.",
TITLE="Textual Conventions for {MIB} Modules Using Performance History Based on 15
Minute Intervals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3593,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document defines a set of Textual Conventions for MIB
modules that make use of performance history data based on 15
minute intervals.

This memo replaces RFC 2493.  Changes relative to RFC 2493 are
summarized in the MIB module's REVISION clause.

This document is a product of the AToM MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3593.txt"
}

@TECHREPORT{rfc3594,
AUTHOR="P. Duffy",
TITLE="{PacketCable} Security Ticket Control {Sub-Option} for the {DHCP}
{CableLabs} Client Configuration {(CCC)} Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3594,
PAGES=7,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document defines a new sub-option for the DHCP CableLabs
Client Configuration (CCC) Option.  This new sub-option will be
used to direct CableLabs Client Devices (CCDs) to invalidate
security tickets stored in CCD non volatile memory (i.e., locally
persisted security tickets).

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3594.txt"
}

@TECHREPORT{rfc3595,
AUTHOR="B. Wijnen",
TITLE="Textual Conventions for {IPv6} Flow Label",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3595,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This MIB module defines textual conventions to represent the commonly
used IPv6 Flow Label.  The intent is that these textual conventions
(TCs) will be imported and used in MIB modules that would otherwise
define their own representations.",
URL="http://www.rfc-editor.org/rfc/rfc3595.txt"
}

@TECHREPORT{rfc3596,
AUTHOR="Sue Thomson and Christian Huitema and V. Ksinant and M. Souissi",
TITLE="{DNS} Extensions to Support {IP} Version 6",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3596,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="This document defines the changes that need to be made to the Domain
Name System (DNS) to support hosts running IP version 6 (IPv6).  The
changes include a resource record type to store an IPv6 address,
a domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing.  The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.

This document is a product of the DNS Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3596.txt"
}

@TECHREPORT{rfc3597,
AUTHOR="A. Gustafsson",
TITLE="Handling of Unknown {DNS} Resource Record {(RR)} Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3597,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="Extending the Domain Name System (DNS) with new Resource Record (RR)
types currently requires changes to name server software.  This
document specifies the changes necessary to allow future DNS
implementations to handle new RR types transparently.

This document is a product of the DNS Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3597.txt"
}

@TECHREPORT{rfc3598,
AUTHOR="K. Murchison",
TITLE="Sieve Email Filtering {--} Subaddress Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3598,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT={On email systems that allow for {"}subaddressing{"} or {"}detailed
addressing{"} (e.g., {"}ken+sieve(at)example.org{"}), it is sometimes
desirable
to make comparisons against these sub-parts of addresses.  This
document defines an extension to the Sieve mail filtering language
that allows users to compare against the user and detail parts of an
address.},
URL="http://www.rfc-editor.org/rfc/rfc3598.txt"
}

@TECHREPORT{rfc3600,
AUTHOR="Ed. J. Reynolds and Ed. S. Ginoza",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3600,
MONTH=nov,
YEAR=2003,
ABSTRACT="This memo contains a snapshot of the state of standardization of protocols
used in the Internet as of October 2, 2003. It lists official protocol
standards and Best Current Practice RFCs; it is not a complete index to the
RFC series. The latest version of this memo is designated STD 1.",
URL="http://www.rfc-editor.org/rfc/rfc3600.txt"
}

@TECHREPORT{rfc3601,
AUTHOR="Claudio Allocchio",
TITLE="Text String Notation for Dial Sequences and Global Switched Telephone
Network {(GSTN)} / {E.164} Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3601,
PAGES=10,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT={This memo describes the full set of notations needed to represent
a text string in a Dial Sequence.  A Dial Sequence is normally
composed of Dual Tone Multi Frequency (DTMF) elements, plus
separators and additional {"}actions{"} (such as {"}wait for
dialtone{"}, {"}pause for N secs{"}, etc.) which could be needed to
successfully establish the connection with the target service:
this includes the cases where subaddresses or DTMF menu navigation
apply.},
URL="http://www.rfc-editor.org/rfc/rfc3601.txt"
}

@TECHREPORT{rfc3602,
AUTHOR="S. Frankel and R. Glenn and S. Kelly",
TITLE="The {AES-CBC} Cipher Algorithm and Its Use with {IPsec}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3602,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document describes the use of the Advanced Encryption Standard
(AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an
explicit Initialization Vector (IV), as a confidentiality mechanism
within the context of the IPsec Encapsulating Security Payload (ESP). 

This document is a product of the IP Security Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3602.txt"
}

@TECHREPORT{rfc3603,
AUTHOR="William Marshall and I. W. Ed. and Flemming Andreasen",
TITLE="Private Session Initiation Protocol {(SIP)} {Proxy-to-Proxy} Extensions for
Supporting the {PacketCable} Distributed Call Signaling Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3603,
PAGES=28,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="In order to deploy a residential telephone service at very large
scale across different domains, it is necessary for trusted elements
owned by different service providers to exchange trusted information
that conveys customer-specific information and expectations about
the parties involved in the call.  This document describes private
extensions to the Session Initiation Protocol (SIP) (RFC3261) for
supporting the exchange of customer information and billing
information between trusted entities in the PacketCable Distributed
Call Signaling Architecture.  These extensions provide mechanisms for
access network coordination to prevent theft of service, customer
originated trace of harassing calls, support for operator services
and emergency services, and support for various other regulatory
issues.  The use of the extensions is only applicable within closed
administrative domains, or among federations of administrative
domains with previously agreed-upon policies where coordination of
charging and other functions is required.",
URL="http://www.rfc-editor.org/rfc/rfc3603.txt"
}

@TECHREPORT{rfc3604,
AUTHOR="Hormuzd M. Khosravi and G. Kullgren and S. Shew and J. Sadler and Akira
Watanabe",
TITLE="Requirements for Adding Optical Support to the General Switch Management
Protocol version 3 {(GSMPv3)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3604,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="This memo provides requirements for adding optical switching support
to the General Switch Management Protocol (GSMP).  It also contains
clarifications and suggested changes to the GSMPv3 specification.

This document is a product of the General Switch Management Protocol
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3604.txt"
}

@TECHREPORT{rfc3605,
AUTHOR="Christian Huitema",
TITLE="Real Time Control Protocol {(RTCP)} attribute in Session Description
Protocol {(SDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3605,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="The Session Description Protocol (SDP) is used to describe the
parameters of media streams used in multimedia sessions.  When a
session requires multiple ports, SDP assumes that these ports have
consecutive numbers.  However, when the session crosses a network
address translation device that also uses port mapping, the ordering
of ports can be destroyed by the translation.  To handle this, we
propose an extension attribute to SDP.

This document is a product of the Multiparty Multimedia Session
Control Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3605.txt"
}

@TECHREPORT{rfc3606,
AUTHOR="F. Ly and M. Noto and A J Smith and E. M. Spiegel and K. Tesink",
TITLE="Definitions of Supplemental Managed Objects for {ATM} Interface",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3606,
PAGES=94,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This memo defines objects used for managing ATM-based interfaces,
devices, and services, in addition to those defined in RFC 2515, the
ATM-MIB, to provide additional support for the management of ATM
Switched Virtual Connections (SVCs) and ATM Permanent Virtual
Connections (PVCs). 

This document is a product of the AToM MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3606.txt"
}

@TECHREPORT{rfc3607,
AUTHOR="M. Leech",
TITLE="Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking
Tool",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3607,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document revisits the so-called Chinese Lottery
massively-parallel cryptanalytic attack.  It explores Internet-based
analogues to the Chinese Lottery, and their potentially-serious
consequences.",
URL="http://www.rfc-editor.org/rfc/rfc3607.txt"
}

@TECHREPORT{rfc3608,
AUTHOR="D. Willis and B. Hoeneisen",
TITLE="Session Initiation Protocol {(SIP)} Extension Header Field for Service
Route Discovery During Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3608,
PAGES=17,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="This document defines a Session Initiation Protocol (SIP) extension
header field used in conjunction with responses to REGISTER requests
to provide a mechanism by which a registrar may inform a registering
user agent (UA) of a service route that the UA may use to request
outbound services from the registrar's domain.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3608.txt"
}

@TECHREPORT{rfc3609,
AUTHOR="R. Bonica and Kireeti  Kompella and D. L. Meyer",
TITLE="Tracing Requirements for Generic Tunnels",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3609,
PAGES=9,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT={This document specifies requirements for a generic route-tracing
application.  It also specifies requirements for a protocol that will
support that application.  Network operators will use the generic
route-tracing application to verify proper operation of the IP
forwarding plane.  They will also use the application to discover
details regarding tunnels that support IP forwarding.

The generic route-tracing application, specified herein, supports a
superset of the functionality that {"}traceroute{"} currently offers.
Like traceroute, the generic route-tracing application can discover
the forwarding path between two interfaces that are contained by an
IP network.  Unlike traceroute, this application can reveal details
regarding tunnels that support the IP forwarding path.

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3609.txt"
}

@TECHREPORT{rfc3610,
AUTHOR="D. Whiting and R. Housley and Niels  Ferguson",
TITLE="Counter with {CBC-MAC} {(CCM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3610,
PAGES=26,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="Counter with CBC-MAC (CCM) is a generic authenticated encryption block
cipher mode.  CCM is defined for use with 128-bit block ciphers, such
as the Advanced Encryption Standard (AES).",
URL="http://www.rfc-editor.org/rfc/rfc3610.txt"
}

@TECHREPORT{rfc3611,
AUTHOR="Timur Friedman and Ramón {Cáceres} and Alan Clark and Eds.",
TITLE="{RTP} Control Protocol Extended Reports {(RTCP} {XR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3611,
PAGES=55,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This document defines the Extended Report (XR) packet type for the
RTP Control Protocol (RTCP), and defines how the use of XR packets
can be signaled by an application if it employs the Session
Description Protocol (SDP).  XR packets are composed of report
blocks, and seven block types are defined here.  The purpose of the
extended reporting format is to convey information that supplements
the six statistics that are contained in the report blocks used by
RTCP's Sender Report (SR) and Receiver Report (RR) packets.  Some
applications, such as multicast inference of network characteristics
(MINC) or voice over IP (VoIP) monitoring, require other and more
detailed statistics.  In addition to the block types defined here,
additional block types may be defined in the future by adhering to
the framework that this document provides.

This document is a product of the Audio/Video Transport Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3611.txt"
}

@TECHREPORT{rfc3612,
AUTHOR="A. Farrel",
TITLE="Applicability Statement for Restart Mechanisms for the Label Distribution
Protocol {(LDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3612,
PAGES=16,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT={This document provides guidance on when it is advisable to implement
some form of Label Distribution Protocol (LDP) restart mechanism and
which approach might be more suitable.  The issues and extensions
described in this document are equally applicable to RFC 3212,
{"}Constraint-Based LSP Setup Using LDP{"}.

This document is a product of the Multiprotocol Label Switching
Working Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3612.txt"
}

@TECHREPORT{rfc3613,
AUTHOR="R. Morgan and K. Hazelton",
TITLE="Definition of a Uniform Resource Name {(URN)} Namespace for the Middleware
Architecture Committee for Education {(MACE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3613,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="This document describes a Uniform Resource Name (URN) namespace for
the Internet2 Middleware Architecture Committee for Education (MACE).
This namespace is for naming persistent resources defined by
MACE, its working groups and other designated subordinates.",
URL="http://www.rfc-editor.org/rfc/rfc3613.txt"
}

@TECHREPORT{rfc3614,
AUTHOR="Jonathan M. Smith",
TITLE="A Uniform Resource Name {(URN)} Namespace for the Motion Picture Experts
Group {(MPEG)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3614,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document describes a Uniform Resource Name (URN) namespace for
the Motion Picture Experts Group (MPEG) for naming persistent
resources as part of the MPEG standards.  Example resources include
technical documents and specifications, eXtensible Markup Language
(XML) Schemas, classification schemes, XML Document Type Definitions
(DTDs), namespaces, style sheets, media assets, and other types of
resources produced or managed by MPEG.",
URL="http://www.rfc-editor.org/rfc/rfc3614.txt"
}

@TECHREPORT{rfc3615,
AUTHOR="J. Gustin and A. Goyens",
TITLE="A Uniform Resource Name {(URN)} Namespace for {SWIFT} Financial Messaging",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3615,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document describes a Uniform Resource Name (URN) namespace that
is managed by SWIFT for usage within messages standardized by SWIFT.",
URL="http://www.rfc-editor.org/rfc/rfc3615.txt"
}

@TECHREPORT{rfc3616,
AUTHOR="F Bellifemine and I. Constantinescu and S. Willmott",
TITLE="A Uniform Resource Name {(URN)} Namespace for Foundation for Intelligent
Physical Agents {(FIPA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3616,
PAGES=8,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document describes a Uniform Resource Name Namespace
Identification (URN NID) for the Foundation for Intelligent Physical
Agents (FIPA). This URN NID will be used for identification of
standard components published by the FIPA standards body in the area
of Agent technology.",
URL="http://www.rfc-editor.org/rfc/rfc3616.txt"
}

@TECHREPORT{rfc3617,
AUTHOR="E. Lear",
TITLE="Uniform Resource Identifier {(URI)} Scheme and Applicability Statement for
the Trivial File Transfer Protocol {(TFTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3617,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL
protocol that has been in use on the Internet for quite a long
time.  While this document discourages its continued use, largely due
to security concerns, we do define a Uniform Resource Identifier (URI)
scheme, as well as discuss the protocol's applicability.",
URL="http://www.rfc-editor.org/rfc/rfc3617.txt"
}

@TECHREPORT{rfc3619,
AUTHOR="Samarth Harish Shah and M. Yip",
TITLE="Extreme Networks' Ethernet Automatic Protection Switching {(EAPS)} Version
1",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3619,
PAGES=7,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="This document describes the Ethernet Automatic Protection
Switching (EAPS) (tm) technology invented by Extreme Networks to
increase the availability and robustness of Ethernet rings.  An
Ethernet ring built using EAPS can have resilience comparable to
that provided by SONET rings, at a lower cost and with fewer
constraints (e.g., ring size).",
URL="http://www.rfc-editor.org/rfc/rfc3619.txt"
}

@TECHREPORT{rfc3620,
AUTHOR="Darren New",
TITLE="The {TUNNEL} Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3620,
PAGES=18,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="This memo describes a Blocks Extensible Exchange Protocol (BEEP)
profile that allows a BEEP peer to serve as an application-layer
proxy.  It allows authorized users to access services through a
firewall.

This document is a product of the Intrusion Detection Exchange Format
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3620.txt"
}

@TECHREPORT{rfc3621,
AUTHOR="A. Berger and D. Romascanu",
TITLE="Power Ethernet {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3621,
PAGES=20,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
This document proposes an extension to the Ethernet-like Interfaces
MIB with a set of objects for managing Power Sourcing Equipment
(PSE).

This document is a product of the Ethernet Interfaces and Hub MIB
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3621.txt"
}

@TECHREPORT{rfc3623,
AUTHOR="J. Moy and P. Pillay-Esnault and A. Lindem",
TITLE="Graceful {OSPF} Restart",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3623,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT={This memo documents an enhancement to the OSPF routing protocol,
whereby an OSPF router can stay on the forwarding path even as its
OSPF software is restarted.  This is called {"}graceful restart{"} or
{"}non-stop forwarding{"}.  A restarting router may not be capable of
adjusting its forwarding in a timely manner when the network
topology changes.  In order to avoid the possible resulting routing
loops, the procedure in this memo automatically reverts to a normal
OSPF restart when such a topology change is detected, or when one or
more of the restarting router's neighbors do not support the
enhancements in this memo.  Proper network operation during a
graceful restart makes assumptions upon the operating environment
of the restarting router; these assumptions are also documented.

This document is a product of the Open Shortest Path First IGP Working
Group of the IETF.},
URL="http://www.rfc-editor.org/rfc/rfc3623.txt"
}

@TECHREPORT{rfc3624,
AUTHOR="B. Foster and D. Auerbach and F. Andreasen",
TITLE="The Media Gateway Control Protocol {(MGCP)} Bulk Audit Package",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3624,
PAGES=19,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="The base Media Gateway Control Protocol (MGCP) includes audit
commands that only allow a Call Agent to audit endpoint and/or
connection state one endpoint at a time.  This document describes a
new MGCP package for bulk auditing of a group of gateway endpoints.
It allows a Call Agent to determine the endpoint naming convention,
the list of instantiated endpoints as well connection and endpoint
state for the group of endpoints.",
URL="http://www.rfc-editor.org/rfc/rfc3624.txt"
}

@TECHREPORT{rfc3625,
AUTHOR="R. Gellens and H. Garudadri",
TITLE="The {QCP} File Format and Media Types for Speech Data",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3625,
PAGES=15,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT={RFC 2658 specifies the streaming format for 3GPP2 13K vocoder (High
Rate Speech Service Option 17 for Wideband Spread Spectrum
Communications Systems, also known as QCELP 13K vocoder) data, but
does not specify a storage format.  Many implementations have been
using the {"}QCP{"} file format (named for its file extension) for
exchanging QCELP 13K data as well as Enhanced Variable Rate Coder
(EVRC) and Selectable Mode Vocoders (SMV) data.  (For example,
Eudora(r), QuickTime(r), and cmda2000(r) handsets).

This document specifies the QCP file format and updates the
audio/qcelp media registration to specify this format for storage, and
registers the audio/evrc-qcp and audio/smv-qcp media types for EVRC
and SMV (respectively) data stored in this format.},
URL="http://www.rfc-editor.org/rfc/rfc3625.txt"
}

@TECHREPORT{rfc3626,
AUTHOR="Ed. T. Clausen and Ed. P. Jacquet",
TITLE="Optimized Link State Routing Protocol {(OLSR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3626,
MONTH=oct,
YEAR=2003,
ABSTRACT="This document describes the Optimized Link State Routing (OLSR) protocol
for mobile ad hoc networks. The protocol is an optimization of the
classical link state algorithm tailored to the requirements of a mobile
wireless LAN. The key concept used in the protocol is that of multipoint
relays (MPRs). MPRs are selected nodes which forward broadcast messages
during the flooding process. This technique substantially reduces the
message overhead as compared to a classical flooding mechanism, where every
node retransmits each message when it receives the first copy of the
message. In OLSR, link state information is generated only by nodes elected
as MPRs. Thus, a second optimization is achieved by minimizing the number
of control messages flooded in the network. As a third optimization, an MPR
node may chose to report only links between itself and its MPR selectors.
Hence, as contrary to the classic link state algorithm, partial link state
information is distributed in the network. This information is then used
for route calculation. OLSR provides optimal routes (in terms of number of
hops). The protocol is particularly suitable for large and dense networks
as the technique of MPRs works well in this context.",
URL="http://www.rfc-editor.org/rfc/rfc3626.txt"
}

@TECHREPORT{rfc3627,
AUTHOR="P. Savola",
TITLE="Use of {/127} Prefix Length Between Routers Considered Harmful",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3627,
PAGES=6,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="In some cases, the operational decision may be to use IPv6 /127
prefix lengths, especially on point-to-point links between routers.
Under certain situations, this may lead to one router claiming both
addresses due to subnet-router anycast being implemented.  This
document discusses the issue and offers a couple of solutions to the
problem; nevertheless, /127 should be avoided between two routers.",
URL="http://www.rfc-editor.org/rfc/rfc3627.txt"
}

@TECHREPORT{rfc3628,
AUTHOR="D. Pinkas and N. Pope and J. Ross",
TITLE="Policy Requirements for {Time-Stamping} Authorities {(TSAs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3628,
PAGES=43,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This document defines requirements for a baseline time-stamp policy
for Time-Stamping Authorities (TSAs) issuing time-stamp tokens,
supported by public key certificates, with an accuracy of one
second or better.  A TSA may define its own policy which enhances
the policy defined in this document.  Such a policy shall
incorporate or further constrain the requirements identified in this
document.",
URL="http://www.rfc-editor.org/rfc/rfc3628.txt"
}

@TECHREPORT{rfc3629,
AUTHOR="F. Yergeau",
TITLE="{UTF-8,} a transformation format of {ISO} 10646",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3629,
PAGES=14,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="ISO/IEC 10646-1 defines a large character set called the Universal
Character Set (UCS) which encompasses most of the world's writing
systems.  The originally proposed encodings of the UCS, however, were
not compatible with many current applications and protocols, and this
has led to the development of UTF-8, the object of this memo.  UTF-8
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 obsoletes and replaces RFC 2279.",
URL="http://www.rfc-editor.org/rfc/rfc3629.txt"
}

@TECHREPORT{rfc3630,
AUTHOR="D. Katz and Kireeti  Kompella and Donald Yeung",
TITLE="Traffic Engineering {(TE)} Extensions to {OSPF} Version 2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3630,
PAGES=14,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document describes extensions to the OSPF protocol version 2 to
support intra-area Traffic Engineering (TE), using Opaque Link State
Advertisements.

This document is a product of the Open Shortest Path First IGP Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3630.txt"
}

@TECHREPORT{rfc3631,
AUTHOR="S. M. Bellovin and J. Schiller and C. Kaufman and Eds.",
TITLE="Security Mechanisms for the Internet",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3631,
PAGES=20,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="Security must be built into Internet Protocols for those protocols to
offer their services securely.  Many security problems can be traced
to improper implementations.  However, even a proper implementation
will have security problems if the fundamental protocol is itself
exploitable.  Exactly how security should be implemented in a
protocol will vary, because of the structure of the protocol itself.
However, there are many protocols for which standard Internet
security mechanisms, already developed, may be applicable.  The
precise one that is appropriate in any given situation can vary.  We
review a number of different choices, explaining the properties of
each.",
URL="http://www.rfc-editor.org/rfc/rfc3631.txt"
}

@TECHREPORT{rfc3632,
AUTHOR="S. Hollenbeck and S. Veeramachaneni and S. Yalamanchilli",
TITLE="{VeriSign} Registry Registrar Protocol {(RRP)} Version {2.0.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3632,
PAGES=8,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This document updates version 1.1.0 of the Network Solutions
Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832.
The changes described in this document combined with the base
specification documented in RFC 2832 specify version 2.0.0 of the
VeriSign Registry Registrar Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc3632.txt"
}

@TECHREPORT{rfc3633,
AUTHOR="O. Troan and R Droms",
TITLE="{IPv6} Prefix Options for Dynamic Host Configuration Protocol {(DHCP)}
version 6",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3633,
PAGES=19,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="The Prefix Delegation options provide a mechanism for automated
delegation of IPv6 prefixes using the Dynamic Host Configuration
Protocol (DHCP).  This mechanism is intended for delegating a
long-lived prefix from a delegating router to a requesting router,
across an administrative boundary, where the delegating router does
not require knowledge about the topology of the links in the network
to which the prefixes will be assigned.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3633.txt"
}

@TECHREPORT{rfc3634,
AUTHOR="K. Luehrs and R. Woundy and J. Bevilacqua and N. Davoust",
TITLE="Key Distribution Center {(KDC)} Server Address Sub-option for the Dynamic
Host Configuration Protocol {(DHCP)} {CableLabs} Client Configuration
{(CCC)} Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3634,
PAGES=7,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="This document defines a new sub-option for the CableLabs Client
Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option
code for conveying the network addresses of Key Distribution Center
(KDC) servers.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3634.txt"
}

@TECHREPORT{rfc3635,
AUTHOR="J. Flick",
TITLE="Definitions of Managed Objects for the Ethernet-like Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3635,
PAGES=64,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing Ethernet-like
interfaces.  This memo obsoletes RFC 2665.  It updates that
specification by including management information useful for the
management of 10 Gigabit per second (Gb/s) Ethernet interfaces.

This document is a product of the Ethernet Interfaces and Hub MIB
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3635.txt"
}

@TECHREPORT{rfc3636,
AUTHOR="J. Flick",
TITLE="Definitions of Managed Objects for {IEEE} {802.3} Medium Attachment Units
{(MAUs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3636,
PAGES=62,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing IEEE 802.3 Medium
Attachment Units (MAUs).  This memo obsoletes RFC 2668.  This memo
extends that specification by including management information useful
for the management of 10 gigabit per second (Gb/s) MAUs.  This memo
also obsoletes RFC 1515.

This document is a product of the Ethernet Interfaces and HubMIB
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3636.txt"
}

@TECHREPORT{rfc3637,
AUTHOR="C. Heard and I. W. Ed.",
TITLE="Definitions of Managed Objects for the Ethernet {WAN} Interface Sublayer",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3637,
PAGES=37,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets.  In particular, it defines objects for managing the
Ethernet Wide Area Network (WAN) Interface Sublayer (WIS).

The MIB module defined in this memo is an extension of the Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface
MIB and is implemented in conjunction with it and with the
Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the
Interfaces Group MIB, and the Inverted Stack Table MIB.

This document is a product of the Ethernet Interfaces and Hub MIB
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3637.txt"
}

@TECHREPORT{rfc3638,
AUTHOR="J. Flick and C. Heard",
TITLE="Applicability Statement for Reclassification of {RFC} 1643 to Historic
Status",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3638,
PAGES=5,
DAYS=15,
MONTH=sep,
YEAR=2003,
ABSTRACT="This memo recommends that RFC 1643 be reclassified as an Historic
document and provides the supporting motivation for that
recommendation.

This document is a product of the Ethernet Interfaces and Hub MIB
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3638.txt"
}

@TECHREPORT{rfc3639,
AUTHOR="M. St. Johns and I. W. Ed. and Geoff Huston",
TITLE="Considerations on the use of a Service Identifier in Packet Headers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3639,
PAGES=8,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="This memo describes some considerations relating to the use of IP
protocol number fields and payload protocol (e.g., TCP) port fields
to identify particular services that may be associated with that port
number or protocol number.",
URL="http://www.rfc-editor.org/rfc/rfc3639.txt"
}

@TECHREPORT{rfc3640,
AUTHOR="J. {Van der Meer} and D. Mackie and V. Swaminathan and D. Singer and P.
Gentric",
TITLE="{RTP} Payload Format for Transport of {MPEG-4} Elementary Streams",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3640,
PAGES=43,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29
WG11) is a working group in ISO that produced the MPEG-4
standard.  MPEG defines tools to compress content such as audio-visual
information into elementary streams.  This specification defines a
simple, but generic RTP payload format for transport of any
non-multiplexed MPEG-4 elementary stream.

This document is a product of the Audio/Video Transport Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3640.txt"
}

@TECHREPORT{rfc3641,
AUTHOR="S. Legg",
TITLE="Generic String Encoding Rules {(GSER)} for {ASN.1} Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3641,
PAGES=16,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="This document defines a set of Abstract Syntax Notation One (ASN.1)
encoding rules, called the Generic String Encoding Rules (GSER), that
produce a human readable text encoding for values of any given ASN.1
data type.",
URL="http://www.rfc-editor.org/rfc/rfc3641.txt"
}

@TECHREPORT{rfc3642,
AUTHOR="S. Legg",
TITLE="Common Elements of Generic String Encoding Rules {(GSER)} Encodings",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3642,
PAGES=13,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="The Generic String Encoding Rules (GSER) describe a human readable
text encoding for an Abstract Syntax Notation One (ASN.1) value of
any ASN.1 type.  Specifications making use of GSER may wish to
provide an equivalent Augmented Backus-Naur Form (ABNF) description
of the GSER encoding for a particular ASN.1 type as a convenience for
implementors.  This document supports such specifications by
providing equivalent ABNF for the GSER encodings for ASN.1 types that
commonly occur in Lightweight Directory Access Protocol (LDAP)
syntaxes.",
URL="http://www.rfc-editor.org/rfc/rfc3642.txt"
}

@TECHREPORT{rfc3643,
AUTHOR="R. A. Weber and M. Rajagopal and F. Travostino and M. O'Donnell and C.
Monia and M. Merhar",
TITLE="Fibre Channel {(FC)} Frame Encapsulation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3643,
PAGES=20,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="This document describes the common Fibre Channel (FC) frame
encapsulation format and a procedure for the measurement and
calculation of frame transit time through the IP network.  This
specification is intended for use by any IETF protocol that
encapsulates FC frames.

This document is a product of the IP Storage Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3643.txt"
}

@TECHREPORT{rfc3644,
AUTHOR="Y. Snir and Y. Ramberg and J. Strassner and R. Cohen and B. W. Moore",
TITLE="Policy Quality of Service {(QoS)} Information Model",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3644,
PAGES=73,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This document presents an object-oriented information model for
representing Quality of Service (QoS) network management policies.
This document is based on the IETF Policy Core Information Model and
its extensions.  It defines an information model for QoS enforcement
for differentiated and integrated services using policy.  It is
important to note that this document defines an information model,
which by definition is independent of any particular data storage
mechanism and access protocol.

This document is a product of the Policy Framework Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3644.txt"
}

@TECHREPORT{rfc3645,
AUTHOR="S. Kwan and Puneet Garg and J. Gilroy and L. Esibov and J. Westhead and
Robert J. Hall",
TITLE="Generic Security Service Algorithm for Secret Key Transaction
Authentication for {DNS} {(GSS-TSIG)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3645,
PAGES=26,
DAYS=15,
MONTH=oct,
YEAR=2003,
ABSTRACT="The Secret Key Transaction Authentication for DNS (TSIG) protocol
provides transaction level authentication for DNS.  TSIG is extensible
through the definition of new algorithms.  This document specifies an
algorithm based on the Generic Security Service Application Program
Interface (GSS-API) (RFC2743).  This document updates RFC 2845.

This document is a product of the DNS Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3645.txt"
}

@TECHREPORT{rfc3646,
AUTHOR="R Droms and I. W. Ed.",
TITLE="{DNS} Configuration options for Dynamic Host Configuration Protocol for
{IPv6} {(DHCPv6)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3646,
PAGES=7,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="This document describes Dynamic Host Configuration Protocol for IPv6
(DHCPv6) options for passing a list of available DNS recursive name
servers and a domain search list to a client.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3646.txt"
}

@TECHREPORT{rfc3647,
AUTHOR="S. Chokhani and W. Ford and R. Sabett and C. Merrill and S. Wu",
TITLE="Internet {X.509} Public Key Infrastructure Certificate Policy and
Certification Practices Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3647,
PAGES=94,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This document presents a framework to assist the writers of
certificate policies or certification practice statements for
participants within public key infrastructures, such as
certification authorities, policy authorities, and communities of
interest that wish to rely on certificates.  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 or a certification practice statement.  This document
supersedes RFC 2527.

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3647.txt"
}

@TECHREPORT{rfc3648,
AUTHOR="J. Whitehead and J. Reschke and I. W. Ed.",
TITLE="Web Distributed Authoring and Versioning {(WebDAV)} Ordered Collections
Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3648,
PAGES=30,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="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.  

This document is a product of the WWW Distributed Authoring and
Versioning Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3648.txt"
}

@TECHREPORT{rfc3650,
AUTHOR="S. Sun and L. Lannom and B. Boesch",
TITLE="Handle System Overview",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3650,
PAGES=21,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This document provides an overview of the Handle System in terms of
its namespace and service architecture, as well as its relationship
to other Internet services such as DNS, LDAP/X.500, and URNs.  The
Handle System is a general-purpose global name service that allows
secured name resolution and administration over networks such as
the Internet.  The Handle System manages handles, which are unique
names for digital objects and other Internet resources.",
URL="http://www.rfc-editor.org/rfc/rfc3650.txt"
}

@TECHREPORT{rfc3651,
AUTHOR="S. Sun and S. Reilly and L. Lannom",
TITLE="Handle System Namespace and Service Definition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3651,
PAGES=41,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="The Handle System is a general-purpose global name service that
allows secured name resolution and administration over the public
Internet.  This document provides a detailed description of the
Handle System namespace, and its data, service, and operation
models.  The namespace definition specifies the handle syntax and
its semantic structure.  The data model defines the data structures
used by the Handle System protocol and any pre-defined data types
for carrying out the handle service.  The service model provides
definitions of various Handle System components and explains how
they work together over the network.  Finally, the Handle System
operation model describes its service operation in terms of
messages transmitted between client and server, and the client
authentication process based on the Handle System authentication
protocol.",
URL="http://www.rfc-editor.org/rfc/rfc3651.txt"
}

@TECHREPORT{rfc3652,
AUTHOR="S. Sun and S. Reilly and L. Lannom and J. Petrone",
TITLE="Handle System Protocol (ver {2.1)} Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3652,
PAGES=53,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="The Handle System is a general-purpose global name service that
allows secured name resolution and administration over the public
Internet.  This document describes the protocol used for client
software to access the Handle System for both handle resolution and
administration.  The protocol specifies the procedure for a client
software to locate the responsible handle server of any given
handle.  It also defines the messages exchanged between the client
and server for any handle operation.",
URL="http://www.rfc-editor.org/rfc/rfc3652.txt"
}

@TECHREPORT{rfc3653,
AUTHOR="J. Boyer and M.  Hughes and J. Reagle",
TITLE="{XML-Signature} {XPath} Filter {2.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3653,
PAGES=15,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="XML Signature recommends a standard means for specifying information
content to be digitally signed and for representing the resulting
digital signatures in XML.  Some applications require the ability to
specify a subset of a given XML document as the information content to
be signed.  The XML Signature specification meets this requirement
with the XPath transform.  However, this transform can be difficult to
implement efficiently with existing technologies.  This specification
defines a new XML Signature transform to facilitate the development of
efficient document subsetting implementations that interoperate under
similar performance profiles.

This document is the W3C XML Signature XPath-Filter 2.0
Recommendation.  This document has been reviewed by W3C Members and
other interested parties and has been endorsed by the Director as a
W3C Recommendation.  It is a stable document and may be used as
reference material or cited as a normative reference from another
document.  W3C's role in making the Recommendation is to draw
attention to the specification and to promote its widespread
deployment.  This enhances the functionality and interoperability of
the Web.

This document is a product of the XML Digital Signatures Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3653.txt"
}

@TECHREPORT{rfc3654,
AUTHOR="H. Khosravi and T. W. Anderson and Eds.",
TITLE="Requirements for Separation of {IP} Control and Forwarding",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3654,
PAGES=18,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This document introduces the Forwarding and Control Element Separation
(ForCES) architecture and defines a set of associated terminology.
This document also defines a set of architectural, modeling, and
protocol requirements to logically separate the control and data
forwarding planes of an IP (IPv4, IPv6, etc.) networking device.

This document is a product of the Forwarding and Control Element
Separation Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3654.txt"
}

@TECHREPORT{rfc3655,
AUTHOR="B. Wellington and O. Gudmundsson",
TITLE="Redefinition of {DNS} Authenticated Data {(AD)} bit",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3655,
PAGES=8,
DAYS=15,
MONTH=nov,
YEAR=2003,
ABSTRACT="This document alters the specification defined in RFC 2535.  Based
on implementation experience, the Authenticated Data (AD) bit in the
DNS header is not useful.  This document redefines the AD bit such
that it is only set if all answers or records proving that no answers
exist in the response has been cryptographically verified or otherwise
meets the server's local security policy.

This document is a product of the DNS Extensions Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3655.txt"
}

@TECHREPORT{rfc3656,
AUTHOR="R. Siemborski",
TITLE="The Mailbox Update {(MUPDATE)} Distributed Mailbox Database Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3656,
MONTH=dec,
YEAR=2003,
ABSTRACT="As the demand for high-performance mail delivery agents increases, it
becomes apparent that single-machine solutions are inadequate to the task,
both because of capacity limits and that the failure of the single machine
means a loss of mail delivery for all users. It is preferable to allow many
machines to share the responsibility of mail delivery.",
URL="http://www.rfc-editor.org/rfc/rfc3656.txt"
}

@TECHREPORT{rfc3658,
AUTHOR="O. Gudmundsson",
TITLE="Delegation Signer {(DS)} Resource Record {(RR)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3658,
MONTH=dec,
YEAR=2003,
ABSTRACT="The delegation signer (DS) resource record (RR) is inserted at a zone cut
(i.e., a delegation point) to indicate that the delegated zone is digitally
signed and that the delegated zone recognizes the indicated key as a valid
zone key for the delegated zone. The DS RR is a modification to the DNS
Security Extensions definition, motivated by operational considerations.
The intent is to use this resource record as an explicit statement about
the delegation, rather than relying on inference.",
URL="http://www.rfc-editor.org/rfc/rfc3658.txt"
}

@TECHREPORT{rfc3660,
AUTHOR="B. Foster and F. Andreasen",
TITLE="Basic Media Gateway Control Protocol {(MGCP)} Packages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3660,
PAGES=64,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="This document provides a basic set of Media Gateway Control Protocol
(MGCP) packages.  The generic, line, trunk, handset, RTP, DTMF
(Dual Tone Multifrequency), announcement server and script packages
are updates of packages from RFC 2705 with additional explanation and
in some cases new versions of these packages.  In addition to these,
five new packages are defined here.  These are the signal list,
resource reservation, media format, supplementary services and digit
map extension packages.",
URL="http://www.rfc-editor.org/rfc/rfc3660.txt"
}

@TECHREPORT{rfc3661,
AUTHOR="B. Foster and C. Sivachelvan",
TITLE="Media Gateway Control Protocol {(MGCP)} Return Code Usage",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3661,
PAGES=24,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="This document provides implementation guidelines for the use of
return codes in RFC 3435, Media Gateway Control Protocol (MGCP)
Version 1.0.  Return codes in RFC 3435 do not cover all possible
specific situations that may ever occur in a gateway.  That is not
possible and not necessary.  What is important is to ensure that the
Call Agent that receives a return code behaves appropriately and
consistently for the given situation.  The purpose of this document is
to provide implementation guidelines to ensure that consistency.",
URL="http://www.rfc-editor.org/rfc/rfc3661.txt"
}

@TECHREPORT{rfc3662,
AUTHOR="R. Bless and K. Nichols and K. Wehrle",
TITLE="A Lower Effort {Per-Domain} Behavior {(PDB)} for Differentiated Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3662,
PAGES=17,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT={This document proposes a differentiated services per-domain behavior
(PDB) whose traffic may be {"}starved{"} (although starvation is not
strictly required) in a properly functioning network.  This is in
contrast to the Internet's {"}best-effort{"} or {"}normal Internet
traffic{"}
model, where prolonged starvation indicates network problems.  In this
sense, the proposed PDB's traffic is forwarded with a {"}lower{"} priority
than the normal {"}best-effort{"} Internet traffic, thus the PDB is
called {"}Lower Effort{"} (LE).  Use of this PDB permits a network
operator to strictly limit the effect of its traffic on
{"}best-effort{"}/{"}normal{"} or all other Internet traffic.  This
document
gives some example uses, but does not propose constraining the PDB's
use to any particular type of traffic.},
URL="http://www.rfc-editor.org/rfc/rfc3662.txt"
}

@TECHREPORT{rfc3663,
AUTHOR="A. Newton",
TITLE="Domain Administrative Data in Lightweight Directory Access Protocol
{(LDAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3663,
MONTH=dec,
YEAR=2003,
ABSTRACT="Domain registration data has typically been exposed to the general public
via Nicname/Whois for administrative purposes. This document describes the
Referral Lightweight Directory Access Protocol (LDAP) Service, an
experimental service using LDAP and well-known LDAP types to make domain
administrative data available.",
URL="http://www.rfc-editor.org/rfc/rfc3663.txt"
}

@TECHREPORT{rfc3665,
AUTHOR="A. R. Johnston and S. Donovan and R. Sparks and C. Cunningham and K.
Summers",
TITLE="Session Initiation Protocol {(SIP)} Basic Call Flow Examples",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3665,
MONTH=dec,
YEAR=2003,
ABSTRACT="This document gives examples of Session Initiation Protocol (SIP) call
flows. Elements in these call flows include SIP User Agents and Clients,
SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP
session establishment. Call flow diagrams and message details are shown.",
URL="http://www.rfc-editor.org/rfc/rfc3665.txt"
}

@TECHREPORT{rfc3666,
AUTHOR="A. R. Johnston and S. Donovan and R. Sparks and C. Cunningham and K.
Summers",
TITLE="Session Initiation Protocol {(SIP)} Public Switched Telephone Network
{(PSTN)} Call Flows",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3666,
MONTH=dec,
YEAR=2003,
ABSTRACT="This document contains best current practice examples of Session Initiation
Protocol (SIP) call flows showing interworking with the Public Switched
Telephone Network (PSTN). Elements in these call flows include SIP User
Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to
PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are
illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN
User Part), and FGB (Feature Group B) circuit associated signaling. PSTN
calls are illustrated using global telephone numbers from the PSTN and
private extensions served on by a PBX (Private Branch Exchange). Call flow
diagrams and message details are shown.",
URL="http://www.rfc-editor.org/rfc/rfc3666.txt"
}

@TECHREPORT{rfc3671,
AUTHOR="K. Zeilenga",
TITLE="Collective Attributes in the Lightweight Directory Access Protocol {(LDAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3671,
PAGES=10,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="X.500 collective attributes allow common characteristics to be shared
between collections of entries.  This document summarizes the X.500
information model for collective attributes and describes use of
collective attributes in LDAP (Lightweight Directory Access Protocol).
This document provides schema definitions for collective attributes
for use in LDAP.",
URL="http://www.rfc-editor.org/rfc/rfc3671.txt"
}

@TECHREPORT{rfc3672,
AUTHOR="K. Zeilenga and S. Legg",
TITLE="Subentries in the Lightweight Directory Access Protocol {(LDAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3672,
PAGES=12,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="In X.500 directories, subentries are special entries used to hold
information associated with a subtree or subtree refinement.  This
document adapts X.500 subentries mechanisms for use with the
Lightweight Directory Access Protocol (LDAP).",
URL="http://www.rfc-editor.org/rfc/rfc3672.txt"
}

@TECHREPORT{rfc3673,
AUTHOR="K. Zeilenga",
TITLE="Lightweight Directory Access Protocol version 3 {(LDAPv3):} All Operational
Attributes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3673,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="The Lightweight Directory Access Protocol (LDAP) supports a mechanism
for requesting the return of all user attributes but not all
operational attributes.  This document describes an LDAP extension
which clients may use to request the return of all operational
attributes.",
URL="http://www.rfc-editor.org/rfc/rfc3673.txt"
}

@TECHREPORT{rfc3674,
AUTHOR="K. Zeilenga",
TITLE="Feature Discovery in Lightweight Directory Access Protocol {(LDAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3674,
PAGES=5,
DAYS=15,
MONTH=dec,
YEAR=2003,
ABSTRACT="The Lightweight Directory Access Protocol (LDAP) is an extensible
protocol with numerous elective features.  This document introduces a
general mechanism for discovery of elective features and extensions
which cannot be discovered using existing mechanisms.",
URL="http://www.rfc-editor.org/rfc/rfc3674.txt"
}

@TECHREPORT{rfc3622,
AUTHOR="M. Mealling",
TITLE="A Uniform Resource Name {(URN)} Namespace for the Liberty Alliance Project",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3622,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document describes a Uniform Resource Name (URN) namespace that
will identify various objects within the Liberty Architecture for
federated network identity.",
URL="http://www.rfc-editor.org/rfc/rfc3622.txt"
}

@TECHREPORT{rfc3657,
AUTHOR="S. Moriai and A. Kato",
TITLE="Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax
{(CMS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3657,
PAGES=14,
DAYS=15,
MONTH=jan,
YEAR=2004,
ABSTRACT="This document specifies the conventions for using the Camellia
encryption algorithm for encryption with the Cryptographic
Message Syntax (CMS).

This document is a product of the S/MIME Mail Security Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3657.txt"
}

@TECHREPORT{rfc3664,
AUTHOR="P. Hoffman",
TITLE="The {AES-XCBC-PRF-128} Algorithm for the Internet Key Exchange Protocol
{(IKE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3664,
PAGES=4,
DAYS=15,
MONTH=jan,
YEAR=2004,
ABSTRACT="Some implementations of IP Security (IPsec) may want to use a
pseudo-random function derived from the Advanced Encryption Standard
(AES).  This document describes such an algorithm, called
AES-XCBC-PRF-128.  

This document is a product of the IP Security Working Group of the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3664.txt"
}

@TECHREPORT{rfc3667,
AUTHOR="S. Bradner",
TITLE="{IETF} Rights in Contributions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3667,
MONTH=feb,
YEAR=2004,
ABSTRACT="The IETF policies about rights in Contributions to the IETF are designed to
ensure that such Contributions can be made available to the IETF and
Internet communities while permitting the authors to retain as many rights
as possible. This memo details the IETF policies on rights in Contributions
to the IETF. It also describes the objectives that the policies are
designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces
Section 10 of RFC 2026.",
URL="http://www.rfc-editor.org/rfc/rfc3667.txt"
}

@TECHREPORT{rfc3668,
AUTHOR="S. Bradner",
TITLE="Intellectual Property Rights in {IETF} Technology",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3668,
MONTH=feb,
YEAR=2004,
ABSTRACT="The IETF policies about Intellectual Property Rights (IPR), such as patent
rights, relative to technologies developed in the IETF are designed to
ensure that IETF working groups and participants have as much information
about any IPR constraints on a technical proposal as possible. The policies
are also intended to benefit the Internet community and the public at
large, while respecting the legitimate rights of IPR holders. This memo
details the IETF policies concerning IPR related to technology worked on
within the IETF. It also describes the objectives that the policies are
designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces
Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2
of RFC 2028, for all purposes, including reference [2] in RFC 2418.",
URL="http://www.rfc-editor.org/rfc/rfc3668.txt"
}

@TECHREPORT{rfc3669,
AUTHOR="S. Brim",
TITLE="Guidelines for Working Groups on Intellectual Property Issues",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3669,
MONTH=feb,
YEAR=2004,
ABSTRACT="This memo lays out a conceptual framework and rules of thumb useful for
working groups dealing with Intellectual Property Rights (IPR) issues. It
documents specific examples of how IPR issues have been dealt with in the
IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3669.txt"
}

@TECHREPORT{rfc3670,
AUTHOR="B. W. Moore and D. Durham and J. Strassner and A. Westerinen and W. Weiss",
TITLE="Information Model for Describing Network Device {QoS} Datapath Mechanisms",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3670,
PAGES=97,
DAYS=15,
MONTH=jan,
YEAR=2004,
ABSTRACT="The purpose of this document is to define an information model to
describe the quality of service (QoS) mechanisms inherent in
different network devices, including hosts.  Broadly speaking,
these mechanisms describe the properties common to selecting and
conditioning traffic through the forwarding path (datapath) of a
network device.  This selection and conditioning of traffic in
the datapath spans both major QoS architectures: Differentiated
Services and Integrated Services.

This document should be used with the QoS Policy
Information Model (QPIM) to model how policies can be defined to
manage and configure the QoS mechanisms (i.e., the
classification, marking, metering, dropping, queuing, and
scheduling functionality) of devices.  Together, these two documents
describe how to write QoS policy rules to configure and manage
the QoS mechanisms present in the datapaths of devices.

This document, as well as QPIM, are information models.  That is, they
represent information independent of a binding to a specific type of
repository.

This document is a product of the Policy Framework Working Group of
the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3670.txt"
}

@TECHREPORT{rfc3675,
AUTHOR="D. Eastlake 3rd",
TITLE=".sex Considered Dangerous",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3675,
PAGES=22,
DAYS=15,
MONTH=feb,
YEAR=2004,
ABSTRACT={Periodically there are proposals to mandate the use of a special top
level name or an IP address bit to flag {"}adult{"} or {"}unsafe{"}
material
or the like.  This document explains why this is an ill considered
idea from the legal, philosophical, and particularly, the technical
points of view.},
URL="http://www.rfc-editor.org/rfc/rfc3675.txt"
}

@TECHREPORT{rfc3676,
AUTHOR="R. Gellens",
TITLE="The {Text/Plain} Format and {DelSp} Parameters",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3676,
MONTH=feb,
YEAR=2004,
ABSTRACT="This specification establishes two parameters (Format and DelSP) to be used
with the Text/Plain media type. In the presence of these parameters,
trailing whitespace is used to indicate flowed lines and a canonical quote
indicator is used to indicate quoted lines. This results in an encoding
which appears as normal Text/Plain in older implementations, since it is in
fact normal Text/Plain, yet provides for superior wrapping/flowing, and
quoting.",
URL="http://www.rfc-editor.org/rfc/rfc3676.txt"
}

@TECHREPORT{rfc3678,
AUTHOR="D. Thaler and B. Fenner and B. Quinn",
TITLE="Socket Interface Extensions for Multicast Source Filters",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3678,
PAGES=18,
DAYS=15,
MONTH=jan,
YEAR=2004,
ABSTRACT="The Internet Group Management Protocol (IGMPv3) for IPv4 and the
Multicast Listener Discovery (MLDv2) for IPv6 add the capability for
applications to express source filters on multicast group memberships,
which allows receiver applications to determine the set of senders
(sources) from which to accept multicast traffic.  This capability
also simplifies support of one-to-many type multicast applications.

This document specifies new socket options and functions to manage
source filters for IP Multicast group memberships.  It also defines
the socket structures to provide input and output arguments to these
new application program interfaces (APIs).  These extensions are
designed to provide access to the source filtering features, while
introducing a minimum of change into the system and providing complete
compatibility for existing multicast applications.

This document is a product of the Multicast \& Anycast Group Membership
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3678.txt"
}

@TECHREPORT{rfc3679,
AUTHOR="R Droms",
TITLE="Unused Dynamic Host Configuration Protocol {(DHCP)} Option Codes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3679,
PAGES=8,
DAYS=15,
MONTH=jan,
YEAR=2004,
ABSTRACT="Prior to the publication of RFC 2489 (which was updated by RFC 2939),
several option codes were assigned to proposed Dynamic Host
Configuration Protocol (DHCP) options that were subsequently never
used.  This document lists those unused option codes and directs IANA
to make these option codes available for assignment to other DHCP
options in the future.

The document also lists several option codes that are not currently
documented in an RFC but should not be made available for
reassignment to future DHCP options.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3679.txt"
}

@TECHREPORT{rfc3680,
AUTHOR="J. Rosenberg",
TITLE="A Session Initiation Protocol {(SIP)} Event Package for Registrations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3680,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document defines a Session Initiation Protocol (SIP) event package for
registrations. Through its REGISTER method, SIP allows a user agent to
create, modify, and delete registrations. Registrations can also be altered
by administrators in order to enforce policy. As a result, these
registrations represent a piece of state in the network that can change
dynamically. There are many cases where a user agent would like to be
notified of changes in this state. This event package defines a mechanism
by which those user agents can request and obtain such notifications.",
URL="http://www.rfc-editor.org/rfc/rfc3680.txt"
}

@TECHREPORT{rfc3681,
AUTHOR="R. Bush and R. Fink",
TITLE="Delegation of {E.F.F.3.IP6.ARPA}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3681,
MONTH=jan,
YEAR=2004,
ABSTRACT="This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS
zone in order to enable reverse lookups for 6bone addresses, and makes
specific recommendations for the process needed to accomplish this.",
URL="http://www.rfc-editor.org/rfc/rfc3681.txt"
}

@TECHREPORT{rfc3682,
AUTHOR="V. Gill and J. Heasley and D. L. Meyer",
TITLE="The Generalized {TTL} Security Mechanism {(GTSM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3682,
MONTH=feb,
YEAR=2004,
ABSTRACT="The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to
protect a protocol stack from CPU-utilization based attacks has been
proposed in many settings (see for example, RFC 2461). This document
generalizes these techniques for use by other protocols such as BGP (RFC
1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding
Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the
Generalized TTL Security Mechanism (GTSM) is most effective in protecting
directly connected protocol peers, it can also provide a lower level of
protection to multi-hop sessions. GTSM is not directly applicable to
protocols employing flooding mechanisms (e.g., multicast), and use of
multi-hop GTSM should be considered on a case-by-case basis.",
URL="http://www.rfc-editor.org/rfc/rfc3682.txt"
}

@TECHREPORT{rfc3683,
AUTHOR="M. P. Rose",
TITLE="A Practice for Revoking Posting Rights to {IETF} Mailing Lists",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3683,
MONTH=mar,
YEAR=2004,
ABSTRACT="All self-governing bodies have ways of managing the scope of participant
interaction. The IETF uses a consensus-driven process for developing
computer-communications standards in an open fashion. An important part of
this consensus-driven process is the pervasive use of mailing lists for
discussion. Notably, in a small number of cases, a participant has engaged
in a denial-of-service attack to disrupt the consensus-driven process.
Regrettably, as these bad faith attacks become more common, the IETF needs
to establish a practice that reduces or eliminates these attacks. This memo
recommends such a practice for use by the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3683.txt"
}

@TECHREPORT{rfc3684,
AUTHOR="R. G. Ogier and F. Templin and M. Lewis",
TITLE="Topology Dissemination Based on {Reverse-Path} Forwarding {(TBRPF)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3684,
MONTH=feb,
YEAR=2004,
ABSTRACT="Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a
proactive, link-state routing protocol designed for mobile ad-hoc networks,
which provides hop-by-hop routing along shortest paths to each destination.
Each node running TBRPF computes a source tree (providing paths to all
reachable nodes) based on partial topology information stored in its
topology table, using a modification of Dijkstra's algorithm. To minimize
overhead, each node reports only *part* of its source tree to neighbors.
TBRPF uses a combination of periodic and differential updates to keep all
neighbors informed of the reported part of its source tree. Each node also
has the option to report additional topology information (up to the full
topology), to provide improved robustness in highly mobile networks. TBRPF
performs neighbor discovery using differential HELLO messages which report
only *changes* in the status of neighbors. This results in HELLO messages
that are much smaller than those of other link-state routing protocols such
as OSPF.",
URL="http://www.rfc-editor.org/rfc/rfc3684.txt"
}

@TECHREPORT{rfc3685,
AUTHOR="C. Daboo",
TITLE="{SIEVE} Email Filtering: Spamtest and {VirusTest} Extensions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3685,
PAGES=9,
DAYS=15,
MONTH=feb,
YEAR=2004,
ABSTRACT={The SIEVE mail filtering language {"}spamtest{"} and {"}virustest{"}
extensions permit users to use simple, portable commands for spam
and virus tests on email messages.  Each extension provides a new
test using matches against numeric 'scores'.  It is the
responsibility of the underlying SIEVE implementation to do the
actual checks that result in values returned by the tests.},
URL="http://www.rfc-editor.org/rfc/rfc3685.txt"
}

@TECHREPORT{rfc3686,
AUTHOR="R. Housley",
TITLE="Using Advanced Encryption Standard {(AES)} Counter Mode With {IPsec}
Encapsulating Security Payload {(ESP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3686,
PAGES=19,
DAYS=15,
MONTH=jan,
YEAR=2004,
ABSTRACT="This document is a product of the IP Security Protocol Working Group
of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3686.txt"
}

@TECHREPORT{rfc3687,
AUTHOR="S. Legg",
TITLE="Lightweight Directory Access Protocol {(LDAP)} and {X.500} Component
Matching Rules",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3687,
PAGES=42,
DAYS=15,
MONTH=feb,
YEAR=2004,
ABSTRACT="The syntaxes of attributes in a Lightweight Directory Access Protocol
(LDAP) or X.500 directory range from simple data types, such as text
string, integer, or boolean, to complex structured data types, such as
the syntaxes of the directory schema operational attributes.  Matching
rules defined for the complex syntaxes usually only
provide the most immediately useful matching capability.  This
document defines generic matching rules that can match any user
selected component parts in an attribute value of any arbitrarily
complex attribute syntax.",
URL="http://www.rfc-editor.org/rfc/rfc3687.txt"
}

@TECHREPORT{rfc3688,
AUTHOR="M. Mealling",
TITLE="The {IETF} {XML} Registry",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3688,
MONTH=jan,
YEAR=2004,
ABSTRACT="This document describes an IANA maintained registry for IETF standards
which use Extensible Markup Language (XML) related items such as
Namespaces, Document Type Declarations (DTDs), Schemas, and Resource
Description Framework (RDF) Schemas.",
URL="http://www.rfc-editor.org/rfc/rfc3688.txt"
}

@TECHREPORT{rfc3689,
AUTHOR="K. Carlberg and R. Atkinson",
TITLE="General Requirements for Emergency Telecommunication Service {(ETS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3689,
PAGES=10,
DAYS=15,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document presents a list of general requirements in support of
Emergency Telecommunications Service (ETS).  Solutions to these
requirements are not presented in this document.  Additional
requirements pertaining to specific applications, or types of
applications, are to be specified in separate document(s).

This document is a product of the Internet Emergency Preparedness
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3689.txt"
}

@TECHREPORT{rfc3690,
AUTHOR="K. Carlberg and R. Atkinson",
TITLE="{IP} Telephony Requirements for Emergency Telecommunication Service {(ETS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3690,
PAGES=7,
DAYS=15,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document presents a list of requirements in support of Emergency
Telecommunications Service (ETS) within the context of IP
telephony.  It is an extension to the general requirements presented
in RFC 3689.  Solutions to these requirements are not presented in
this document.

This document is a product of the Internet Emergency Preparedness
Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3690.txt"
}

@TECHREPORT{rfc3691,
AUTHOR="A. Melnikov",
TITLE="Internet Message Access Protocol {(IMAP)} {UNSELECT} command",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3691,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document defines an UNSELECT command that can be used to close the
current mailbox in an Internet Message Access Protocol - version 4 (IMAP4)
session without expunging it. Certain types of IMAP clients need to release
resources associated with the selected mailbox without selecting a
different mailbox. While IMAP4 provides this functionality (via a SELECT
command with a nonexistent mailbox name or reselecting the same mailbox
with EXAMINE command), a more clean solution is desirable.",
URL="http://www.rfc-editor.org/rfc/rfc3691.txt"
}

@TECHREPORT{rfc3692,
AUTHOR="T. Narten",
TITLE="Assigning Experimental and Testing Numbers Considered Useful",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3692,
MONTH=jan,
YEAR=2004,
ABSTRACT="When experimenting with or extending protocols, it is often necessary to
use some sort of protocol number or constant in order to actually test or
experiment with the new function, even when testing in a closed
environment. For example, to test a new DHCP option, one needs an option
number to identify the new function. This document recommends that when
writing IANA Considerations sections, authors should consider assigning a
small range of numbers for experimentation purposes that implementers can
use when testing protocol extensions or other new features. This document
reserves some ranges of numbers for experimentation purposes in specific
protocols where the need to support experimentation has been identified.",
URL="http://www.rfc-editor.org/rfc/rfc3692.txt"
}

@TECHREPORT{rfc3693,
AUTHOR="J. Cuellar and J. Morris and D. Mulligan and J. Peterson and J. Polk",
TITLE="Geopriv Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3693,
MONTH=feb,
YEAR=2004,
ABSTRACT="Location-based services, navigation applications, emergency services,
management of equipment in the field, and other location-dependent services
need geographic location information about a Target (such as a user,
resource or other entity). There is a need to securely gather and transfer
location information for location services, while at the same time protect
the privacy of the individuals involved.",
URL="http://www.rfc-editor.org/rfc/rfc3693.txt"
}

@TECHREPORT{rfc3694,
AUTHOR="M. Danley and D. Mulligan and J. Morris and J. Peterson",
TITLE="Threat Analysis of the Geopriv Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3694,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document provides some analysis of threats against the Geopriv
protocol architecture. It focuses on protocol threats, threats that result
from the storage of data by entities in the architecture, and threats posed
by the abuse of information yielded by Geopriv. Some security properties
that meet these threats are enumerated as a reference for Geopriv
requirements.",
URL="http://www.rfc-editor.org/rfc/rfc3694.txt"
}

@TECHREPORT{rfc3695,
AUTHOR="M. Luby and L. Vicisano",
TITLE="Compact Forward Error Correction {(FEC)} Schemes",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3695,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document introduces some Forward Error Correction (FEC) schemes that
supplement the FEC schemes described in RFC 3452. The primary benefits of
these additional FEC schemes are that they are designed for reliable bulk
delivery of large objects using a more compact FEC Payload ID, and they can
be used to sequentially deliver blocks of an object of indeterminate
length. Thus, they more flexibly support different delivery models with
less packet header overhead.",
URL="http://www.rfc-editor.org/rfc/rfc3695.txt"
}

@TECHREPORT{rfc3696,
AUTHOR="J. Klensin",
TITLE="Application Techniques for Checking and Transformation of Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3696,
MONTH=feb,
YEAR=2004,
ABSTRACT="Many Internet applications have been designed to deduce top-level domains
(or other domain name labels) from partial information. The introduction of
new top-level domains, especially non-country-code ones, has exposed flaws
in some of the methods used by these applications. These flaws make it more
difficult, or impossible, for users of the applications to access the full
Internet. This memo discusses some of the techniques that have been used
and gives some guidance for minimizing their negative impact as the domain
name environment evolves. This document draws summaries of the applicable
rules together in one place and supplies references to the actual
standards.",
URL="http://www.rfc-editor.org/rfc/rfc3696.txt"
}

@TECHREPORT{rfc3697,
AUTHOR="J. Rajahalme and A. Conta and B. E. Carpenter and S. E. Deering",
TITLE="{IPv6} Flow Label Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3697,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document specifies the IPv6 Flow Label field and the minimum
requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding
labeled packets, and flow state establishment methods. Even when mentioned
as examples of possible uses of the flow labeling, more detailed
requirements for specific use cases are out of scope for this document.",
URL="http://www.rfc-editor.org/rfc/rfc3697.txt"
}

@TECHREPORT{rfc3698,
AUTHOR="Ed. K. Zeilenga",
TITLE="Lightweight Directory Access Protocol {(LDAP):} Additional Matching Rules",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3698,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document provides a collection of matching rules for use with the
Lightweight Directory Access Protocol (LDAP). As these matching rules are
simple adaptations of matching rules specified for use with the X.500
Directory, most are already in wide use.",
URL="http://www.rfc-editor.org/rfc/rfc3698.txt"
}

@TECHREPORT{rfc3700,
AUTHOR="Ed. J. Reynolds and Ed. S. Ginoza",
TITLE="Internet Official Protocol Standards",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3700,
MONTH=jul,
YEAR=2004,
ABSTRACT="This memo contains a snapshot of the state of standardization of protocols
used in the Internet as of July 22, 2004. It lists official protocol
standards and Best Current Practice RFCs; it is not a complete index to the
RFC series. The latest version of this memo is designated STD 1.",
URL="http://www.rfc-editor.org/rfc/rfc3700.txt"
}

@TECHREPORT{rfc3701,
AUTHOR="R. Fink and R. Hinden",
TITLE="6bone {(IPv6} Testing Address Allocation) Phaseout",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3701,
MONTH=mar,
YEAR=2004,
ABSTRACT="The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to
enable various IPv6 testing as well as to assist in the transitioning of
IPv6 into the Internet. It operates under the IPv6 address allocation
3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it
is appropriate to plan for the phaseout of the 6bone. This document
establishes a plan for a multi-year phaseout of the 6bone and its address
allocation on the assumption that the IETF is the appropriate place to
determine this.",
URL="http://www.rfc-editor.org/rfc/rfc3701.txt"
}

@TECHREPORT{rfc3702,
AUTHOR="J. Loughney and G. Camarillo",
TITLE="Authentication, Authorization, and Accounting Requirements for the Session
Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3702,
MONTH=feb,
YEAR=2004,
ABSTRACT="As Session Initiation Protocol (SIP) services are deployed on the Internet,
there is a need for authentication, authorization, and accounting of SIP
sessions. This document sets out the basic requirements for this work.",
URL="http://www.rfc-editor.org/rfc/rfc3702.txt"
}

@TECHREPORT{rfc3703,
AUTHOR="J. Strassner and B. W. Moore and R. Moats and E. Ellesson",
TITLE="Policy Core Lightweight Directory Access Protocol {(LDAP)} Schema",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3703,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document defines a mapping of the Policy Core Information Model to a
form that can be implemented in a directory that uses Lightweight Directory
Access Protocol (LDAP) as its access protocol. This model defines two
hierarchies of object classes: structural classes representing information
for representing and controlling policy data as specified in RFC 3060, and
relationship classes that indicate how instances of the structural classes
are related to each other. Classes are also added to the LDAP schema to
improve the performance of a client's interactions with an LDAP server when
the client is retrieving large amounts of policy-related information. These
classes exist only to optimize LDAP retrievals: there are no classes in the
information model that correspond to them.",
URL="http://www.rfc-editor.org/rfc/rfc3703.txt"
}

@TECHREPORT{rfc3704,
AUTHOR="F. Baker and P. Savola",
TITLE="Ingress Filtering for Multihomed Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3704,
MONTH=mar,
YEAR=2004,
ABSTRACT="BCP 38, RFC 2827, is designed to limit the impact of distributed denial of
service attacks, by denying traffic with spoofed addresses access to the
network, and to help ensure that traffic is traceable to its correct source
network. As a side effect of protecting the Internet against such attacks,
the network implementing the solution also protects itself from this and
other attacks, such as spoofed management access to networking equipment.
There are cases when this may create problems, e.g., with multihoming. This
document describes the current ingress filtering operational mechanisms,
examines generic issues related to ingress filtering, and delves into the
effects on multihoming in particular. This memo updates RFC 2827.",
URL="http://www.rfc-editor.org/rfc/rfc3704.txt"
}

@TECHREPORT{rfc3705,
AUTHOR="B. Ray and R. Abbi",
TITLE="High Capacity Textual Conventions for {MIB} Modules Using Performance
History Based on 15 Minute Intervals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3705,
PAGES=11,
DAYS=15,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document presents a set of High Capacity Textual Conventions
for use in MIB modules which require performance history based upon
15 minute intervals.  The Textual Conventions defined in this
document extend the conventions presented in RFC 3593 to 64 bit
resolution using the conventions presented in RFC 2856.

This document is a product of the ADSL MIB Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3705.txt"
}

@TECHREPORT{rfc3706,
AUTHOR="G. Huang and S. Beaulieu and D. Rochefort",
TITLE="A {Traffic-Based} Method of Detecting Dead Internet Key Exchange {(IKE)}
Peers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3706,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document describes the method detecting a dead Internet Key Exchange
(IKE) peer that is presently in use by a number of vendors. The method,
called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize
the number of IKE messages that are needed to confirm liveness. DPD, like
other keepalive mechanisms, is needed to determine when to perform IKE peer
failover, and to reclaim lost resources.",
URL="http://www.rfc-editor.org/rfc/rfc3706.txt"
}

@TECHREPORT{rfc3707,
AUTHOR="A. Newton",
TITLE="Cross Registry Internet Service Protocol {(CRISP)} Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3707,
PAGES=26,
DAYS=15,
MONTH=feb,
YEAR=2004,
ABSTRACT="Internet registries expose administrative and operational data via
varying directory services.  This document defines functional
requirements for the directory services of domain registries and the
common base requirements for extending the use of these services for
other types of Internet registries.

This document is a product of the Cross Registry Information Service
Protocol Working Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3707.txt"
}

@TECHREPORT{rfc3708,
AUTHOR="E. Blanton and M. Allman",
TITLE="Using {TCP} Duplicate Selective Acknowledgement {(DSACKs)} and Stream
Control Transmission Protocol {(SCTP)} Duplicate Transmission Sequence
Numbers {(TSNs)} to Detect Spurious Retransmissions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3708,
MONTH=feb,
YEAR=2004,
ABSTRACT="TCP and Stream Control Transmission Protocol (SCTP) provide notification of
duplicate segment receipt through Duplicate Selective Acknowledgement
(DSACKs) and Duplicate Transmission Sequence Number (TSN) notification,
respectively. This document presents conservative methods of using this
information to identify unnecessary retransmissions for various
applications.",
URL="http://www.rfc-editor.org/rfc/rfc3708.txt"
}

@TECHREPORT{rfc3709,
AUTHOR="S. Santesson and R. Housley and T. Freeman",
TITLE="Internet {X.509} Public Key Infrastructure: Logotypes in {X.509}
Certificates",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3709,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document specifies a certificate extension for including logotypes in
public key certificates and attribute certificates.",
URL="http://www.rfc-editor.org/rfc/rfc3709.txt"
}

@TECHREPORT{rfc3710,
AUTHOR="H. Alvestrand",
TITLE="An {IESG} charter",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3710,
MONTH=feb,
YEAR=2004,
ABSTRACT="This memo provides a charter for the Internet Engineering Steering Group
(IESG), a management function of the Internet Engineering Task Force
(IETF). It is meant to document the charter of the IESG as it is presently
understood.",
URL="http://www.rfc-editor.org/rfc/rfc3710.txt"
}

@TECHREPORT{rfc3711,
AUTHOR="M. Baugher and D. McGrew and M. Naslund and E. Carrara and K. Norrman",
TITLE="The Secure Real-time Transport Protocol {(SRTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3711,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document describes the Secure Real-time Transport Protocol
   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
   can provide confidentiality, message authentication, and replay
   protection to the RTP traffic and to the control traffic for RTP, the
   Real-time Transport Control Protocol (RTCP).",
URL="http://www.rfc-editor.org/rfc/rfc3711.txt"
}

@TECHREPORT{rfc3712,
AUTHOR="P. Fleming and I. McDonald",
TITLE="Lightweight Directory Access Protocol {(LDAP):} Schema for Printer Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3712,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document defines a schema, object classes and attributes, for printers
and printer services, for use with directories that support Lightweight
Directory Access Protocol v3 (LDAP-TS). This document is based on the
printer attributes listed in Appendix E of Internet Printing Protocol/1.1
(IPP) (RFC 2911). A few additional printer attributes are based on
definitions in the Printer MIB (RFC 1759).",
URL="http://www.rfc-editor.org/rfc/rfc3712.txt"
}

@TECHREPORT{rfc3713,
AUTHOR="M. Matsui and J. Nakajima and S. Moriai",
TITLE="A Description of the Camellia Encryption Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3713,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document describes the Camellia encryption algorithm. Camellia is a
block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The
algorithm description is presented together with key scheduling part and
data randomizing part.",
URL="http://www.rfc-editor.org/rfc/rfc3713.txt"
}

@TECHREPORT{rfc3715,
AUTHOR="B. Aboba and W. J. Dixon",
TITLE="{IPsec-Network} Address Translation {(NAT)} Compatibility Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3715,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document describes known incompatibilities between Network Address
Translation (NAT) and IPsec, and describes the requirements for addressing
them. Perhaps the most common use of IPsec is in providing virtual private
networking capabilities. One very popular use of Virtual Private Networks
(VPNs) is to provide telecommuter access to the corporate Intranet. Today,
NATs are widely deployed in home gateways, as well as in other locations
likely to be used by telecommuters, such as hotels. The result is that
IPsec-NAT incompatibilities have become a major barrier in the deployment
of IPsec in one of its principal uses.",
URL="http://www.rfc-editor.org/rfc/rfc3715.txt"
}

@TECHREPORT{rfc3717,
AUTHOR="B. Rajagopalan and J. Luciani and Daniel O. Awduche",
TITLE="{IP} over Optical Networks: A Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3717,
MONTH=mar,
YEAR=2004,
ABSTRACT="The Internet transport infrastructure is moving towards a model of
high-speed routers interconnected by optical core networks. The
architectural choices for the interaction between IP and optical network
layers, specifically, the routing and signaling aspects, are maturing. At
the same time, a consensus has emerged in the industry on utilizing
IP-based protocols for the optical control plane. This document defines a
framework for IP over Optical networks, considering both the IP-based
control plane for optical networks as well as IP-optical network
interactions (together referred to as IP over optical networks).",
URL="http://www.rfc-editor.org/rfc/rfc3717.txt"
}

@TECHREPORT{rfc3718,
AUTHOR="R. A. McGowan",
TITLE="A Summary of Unicode Consortium Procedures, Policies, Stability, and Public
Access",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3718,
MONTH=feb,
YEAR=2004,
ABSTRACT="This memo describes various internal workings of the Unicode Consortium for
the benefit of participants in the IETF. It is intended solely for
informational purposes. Included are discussions of how the decision-making
bodies of the Consortium work and their procedures, as well as information
on public access to the character encoding \& standardization processes.",
URL="http://www.rfc-editor.org/rfc/rfc3718.txt"
}

@TECHREPORT{rfc3719,
AUTHOR="Ed. J. Parker",
TITLE="Recommendations for Interoperable Networks using Intermediate System to
Intermediate System {(IS-IS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3719,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document discusses a number of differences between the Intermediate
System to Intermediate System (IS-IS) protocol as described in ISO 10589
and the protocol as it is deployed today. These differences are discussed
as a service to those implementing, testing, and deploying the IS-IS
Protocol. A companion document discusses differences between the protocol
described in RFC 1195 and the protocol as it is deployed today for routing
IP traffic.",
URL="http://www.rfc-editor.org/rfc/rfc3719.txt"
}

@TECHREPORT{rfc3720,
AUTHOR="J. Satran and K. Meth and C. Sapuntzakis and M. Chadalapaka and E. Zeidner",
TITLE="Internet Small Computer Systems Interface {(iSCSI)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3720,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document describes a transport protocol for Internet Small Computer
Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims
to be fully compliant with the standardized SCSI architecture model.",
URL="http://www.rfc-editor.org/rfc/rfc3720.txt"
}

@TECHREPORT{rfc3721,
AUTHOR="M. Bakke and J. Hafner and J. Hufferd and K. Voruganti and M. Krueger",
TITLE="Internet Small Computer Systems Interface {(iSCSI)} Naming and Discovery",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3721,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document provides examples of the Internet Small Computer Systems
Interface (iSCSI; or SCSI over TCP) name construction and discussion of
discovery of iSCSI resources (targets) by iSCSI initiators. This document
complements the iSCSI protocol document. Flexibility is the key guiding
principle behind this document. That is, an effort has been made to satisfy
the needs of both small isolated environments, as well as large
environments requiring secure/scalable solutions.",
URL="http://www.rfc-editor.org/rfc/rfc3721.txt"
}

@TECHREPORT{rfc3722,
AUTHOR="M. Bakke",
TITLE="String Profile for Internet Small Computer Systems Interface {(iSCSI)}
Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3722,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document describes how to prepare internationalized iSCSI names to
increase the likelihood that name input and comparison work in ways that
make sense for typical users throughout the world.",
URL="http://www.rfc-editor.org/rfc/rfc3722.txt"
}

@TECHREPORT{rfc3723,
AUTHOR="B. Aboba and J. Tseng and J. T. Walker and V. Rangan and F. Travostino",
TITLE="Securing Block Storage Protocols over {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3723,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document discusses how to secure block storage and storage discovery
protocols running over IP (Internet Protocol) using IPsec and IKE (Internet
Key Exchange). Threat models and security protocols are developed for iSCSI
(Internet Protocol Small Computer System Interface), iFCP (Internet Fibre
Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well
as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location
Protocol v2) discovery protocols. Performance issues and resource
constraints are analyzed.",
URL="http://www.rfc-editor.org/rfc/rfc3723.txt"
}

@TECHREPORT{rfc3724,
AUTHOR="Ed. J. Kempf and Ed. R. Austein",
TITLE="The Rise of the Middle and the Future of {End-to-End:} Reflections on the
Evolution of the Internet Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3724,
MONTH=mar,
YEAR=2004,
ABSTRACT="The end-to-end principle is the core architectural guideline of the
Internet. In this document, we briefly examine the development of the
end-to-end principle as it has been applied to the Internet architecture
over the years. We discuss current trends in the evolution of the Internet
architecture in relation to the end-to-end principle, and try to draw some
conclusion about the evolution of the end-to-end principle, and thus for
the Internet architecture which it supports, in light of these current
trends.",
URL="http://www.rfc-editor.org/rfc/rfc3724.txt"
}

@TECHREPORT{rfc3725,
AUTHOR="J. Rosenberg and J. Peterson and Henning Schulzrinne and G. Camarillo",
TITLE="Best Current Practices for Third Party Call Control (3pcc) in the Session
Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3725,
MONTH=apr,
YEAR=2004,
ABSTRACT="Third party call control refers to the ability of one entity to
create a call in which communication is actually between other
parties.  Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP).  However,
there are several possible approaches, each with different benefits
and drawbacks.  This document discusses best current practices for
the usage of SIP for third party call control.",
URL="http://www.rfc-editor.org/rfc/rfc3725.txt"
}

@TECHREPORT{rfc3726,
AUTHOR="Marcus Brunner",
TITLE="Requirements for Signaling Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3726,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document defines requirements for signaling across different network
environments, such as across administrative and/or technology domains.
Signaling is mainly considered for Quality of Service (Qos) such as the
Resource Reservation Protocol (RSVP). However, in recent years, several
other applications of signaling have been defined. For example, signaling
for label distribution in Multiprotocol Label Switching (MPLS) or signaling
to middleboxes. To achieve wide applicability of the requirements, the
starting point is a diverse set of scenarios/use cases concerning various
types of networks and application interactions. This document presents the
assumptions before listing the requirements. The requirements are grouped
according to areas such as architecture and design goals, signaling flows,
layering, performance, flexibility, security, and mobility.",
URL="http://www.rfc-editor.org/rfc/rfc3726.txt"
}

@TECHREPORT{rfc3727,
AUTHOR="S. Legg",
TITLE="{ASN.1} Module Definition for the {LDAP} and {X.500} Component Matching
Rules",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3727,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document updates the specification of the component matching rules for
Lightweight Directory Access Protocol (LDAP) and X.500 directories
(RFC3687) by collecting the Abstract Syntax Notation One (ASN.1)
definitions of the component matching rules into an appropriately
identified ASN.1 module so that other specifications may reference the
component matching rule definitions from within their own ASN.1 modules.",
URL="http://www.rfc-editor.org/rfc/rfc3727.txt"
}

@TECHREPORT{rfc3728,
AUTHOR="B. Ray and R. Abbi",
TITLE="Definitions of Managed Objects for Very High Speed Digital Subscriber Lines
{(VDSL)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3728,
MONTH=feb,
YEAR=2004,
ABSTRACT="This document defines a Management Information Base (MIB) module for use
with network management protocols in the Internet community. In particular,
it describes objects used for managing Very High Speed Digital Subscriber
Line (VDSL) interfaces.",
URL="http://www.rfc-editor.org/rfc/rfc3728.txt"
}

@TECHREPORT{rfc3729,
AUTHOR="S. Waldbusser",
TITLE="Application Performance Measurement {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3729,
MONTH=mar,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for measuring the application performance as
experienced by end-users.",
URL="http://www.rfc-editor.org/rfc/rfc3729.txt"
}

@TECHREPORT{rfc3730,
AUTHOR="S. Hollenbeck",
TITLE="Extensible Provisioning Protocol {(EPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3730,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document describes an application layer client-server protocol for the
provisioning and management of objects stored in a shared central
repository. Specified in XML, the protocol defines generic object
management operations and an extensible framework that maps protocol
operations to objects. This document includes a protocol specification, an
object mapping template, and an XML media type registration.",
URL="http://www.rfc-editor.org/rfc/rfc3730.txt"
}

@TECHREPORT{rfc3731,
AUTHOR="S. Hollenbeck",
TITLE="Extensible Provisioning Protocol {(EPP)} Domain Name Mapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3731,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document describes an Extensible Provisioning Protocol (EPP) mapping
for the provisioning and management of Internet domain names stored in a
shared central repository. Specified in XML, the mapping defines EPP
command syntax and semantics as applied to domain names.",
URL="http://www.rfc-editor.org/rfc/rfc3731.txt"
}

@TECHREPORT{rfc3732,
AUTHOR="S. Hollenbeck",
TITLE="Extensible Provisioning Protocol {(EPP)} Host Mapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3732,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document describes an Extensible Provisioning Protocol (EPP) mapping
for the provisioning and management of Internet host names stored in a
shared central repository. Specified in XML, the mapping defines EPP
command syntax and semantics as applied to host names.",
URL="http://www.rfc-editor.org/rfc/rfc3732.txt"
}

@TECHREPORT{rfc3733,
AUTHOR="S. Hollenbeck",
TITLE="Extensible Provisioning Protocol {(EPP)} Contact Mapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3733,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document describes an Extensible Provisioning Protocol (EPP) mapping
for the provisioning and management of individual or organizational social
information identifiers (known as contacts) stored in a shared central
repository. Specified in Extensible Markup Language (XML), the mapping
defines EPP command syntax and semantics as applied to contacts.",
URL="http://www.rfc-editor.org/rfc/rfc3733.txt"
}

@TECHREPORT{rfc3734,
AUTHOR="S. Hollenbeck",
TITLE="Extensible Provisioning Protocol {(EPP)} Transport Over {TCP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3734,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document describes how an Extensible Provisioning Protocol (EPP)
session is mapped onto a single Transmission Control Protocol (TCP)
connection. This mapping requires use of the Transport Layer Security (TLS)
protocol to protect information exchanged between an EPP client and an EPP
server.",
URL="http://www.rfc-editor.org/rfc/rfc3734.txt"
}

@TECHREPORT{rfc3735,
AUTHOR="S. Hollenbeck",
TITLE="Guidelines for Extending the Extensible Provisioning Protocol {(EPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3735,
MONTH=mar,
YEAR=2004,
ABSTRACT="The Extensible Provisioning Protocol (EPP) is an application layer
client-server protocol for the provisioning and management of objects
stored in a shared central repository. Specified in XML, the protocol
defines generic object management operations and an extensible framework
that maps protocol operations to objects. This document presents guidelines
for use of EPP's extension mechanisms to define new features and object
management capabilities.",
URL="http://www.rfc-editor.org/rfc/rfc3735.txt"
}

@TECHREPORT{rfc3736,
AUTHOR="R Droms",
TITLE="Stateless Dynamic Host Configuration Protocol {(DHCP)} Service for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3736,
MONTH=apr,
YEAR=2004,
ABSTRACT="Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is
used by nodes to obtain configuration information, such as the addresses of
DNS recursive name servers, that does not require the maintenance of any
dynamic state for individual clients. A node that uses stateless DHCP must
have obtained its IPv6 addresses through some other mechanism, typically
stateless address autoconfiguration. This document explains which parts of
RFC 3315 must be implemented in each of the different kinds of DHCP agents
so that agent can support stateless DHCP.",
URL="http://www.rfc-editor.org/rfc/rfc3736.txt"
}

@TECHREPORT{rfc3737,
AUTHOR="B. Wijnen and A. Bierman",
TITLE="{IANA} Guidelines for the Registry of Remote Monitoring {(RMON)} {MIB}
modules",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3737,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document defines the procedures for IANA to administer and maintain
the Object Identifier (OID) tree under the Remote Monitoring (rmon) root.
This memo also documents the currently assigned values.",
URL="http://www.rfc-editor.org/rfc/rfc3737.txt"
}

@TECHREPORT{rfc3738,
AUTHOR="M. Luby and V. Goyal",
TITLE="Wave and Equation Based Rate Control {(WEBRC)} Building Block",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3738,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document specifies Wave and Equation Based Rate Control (WEBRC), which
provides rate and congestion control for data delivery. WEBRC is
specifically designed to support protocols using IP multicast. It provides
multiple-rate, congestion-controlled delivery to receivers, i.e., different
receivers joined to the same session may be receiving packets at different
rates depending on the bandwidths of their individual connections to the
sender and on competing traffic along these connections. WEBRC requires no
feedback from receivers to the sender, i.e., it is a completely
receiver-driven congestion control protocol. Thus, it is designed to scale
to potentially massive numbers of receivers attached to a session from a
single sender. Furthermore, because each individual receiver adjusts to the
available bandwidth between the sender and that receiver, there is the
potential to deliver data to each individual receiver at the fastest
possible rate for that receiver, even in a highly heterogeneous network
architecture, using a single sender.",
URL="http://www.rfc-editor.org/rfc/rfc3738.txt"
}

@TECHREPORT{rfc3740,
AUTHOR="T. Hardjono and B. X. Weis",
TITLE="The Multicast Group Security Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3740,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document provides an overview and rationale of the multicast security
architecture used to secure data packets of large multicast groups. The
document begins by introducing a Multicast Security Reference Framework,
and proceeds to identify the security services that may be part of a secure
multicast solution.",
URL="http://www.rfc-editor.org/rfc/rfc3740.txt"
}

@TECHREPORT{rfc3741,
AUTHOR="J. Boyer and D. Eastlake 3rd and J. Reagle",
TITLE="Exclusive {XML} Canonicalization, Version {1.0}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3741,
MONTH=mar,
YEAR=2004,
ABSTRACT="Canonical XML specifies a standard serialization of XML that, when applied
to a subdocument, includes the subdocument's ancestor context including all
of the namespace declarations and attributes in the xml: namespace.
However, some applications require a method which, to the extent practical,
excludes ancestor context from a canonicalized subdocument. For example,
one might require a digital signature over an XML payload (subdocument) in
an XML message that will not break when that subdocument is removed from
its original message and/or inserted into a different context. This
requirement is satisfied by Exclusive XML Canonicalization.",
URL="http://www.rfc-editor.org/rfc/rfc3741.txt"
}

@TECHREPORT{rfc3742,
AUTHOR="S. Floyd",
TITLE="Limited {Slow-Start} for {TCP} with Large Congestion Windows",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3742,
MONTH=mar,
YEAR=2004,
ABSTRACT="This document describes an optional modification for TCP's slow-start for
use with TCP connections with large congestion windows. For TCP connections
that are able to use congestion windows of thousands (or tens of thousands)
of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the
current slow-start procedure can result in increasing the congestion window
by thousands of segments in a single round-trip time. Such an increase can
easily result in thousands of packets being dropped in one round-trip time.
This is often counter-productive for the TCP flow itself, and is also hard
on the rest of the traffic sharing the congested link. This note describes
Limited Slow-Start as an optional mechanism for limiting the number of
segments by which the congestion window is increased for one window of data
during slow-start, in order to improve performance for TCP connections with
large congestion windows.",
URL="http://www.rfc-editor.org/rfc/rfc3742.txt"
}

@TECHREPORT{rfc3743,
AUTHOR="Kazuki Konishi and K. Hong Huang and Haoli Qian and Ya-Tien Ko",
TITLE="Joint Engineering Team {(JET)} Guidelines for Internationalized Domain
Names {(IDN)} Registration and Administration for Chinese, Japanese, and
Korean",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3743,
MONTH=apr,
YEAR=2004,
ABSTRACT="Achieving internationalized access to domain names raises many complex
issues. These are associated not only with basic protocol design, such as
how names are represented on the network, compared, and converted to
appropriate forms, but also with issues and options for deployment,
transition, registration, and administration.",
URL="http://www.rfc-editor.org/rfc/rfc3743.txt"
}

@TECHREPORT{rfc3744,
AUTHOR="G. Clemm and J. Reschke and E. Sedlar and J. Whitehead and U. C. Santa Cruz",
TITLE="Web Distributed Authoring and Versioning {(WebDAV)} Access Control Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3744,
MONTH=may,
YEAR=2004,
ABSTRACT="This document specifies a set of methods, headers, message bodies,
properties, and reports that define Access Control extensions to the WebDAV
Distributed Authoring Protocol. This protocol permits a client to read and
modify access control lists that instruct a server whether to allow or deny
operations upon a resource (such as HyperText Transfer Protocol (HTTP)
method invocations) by a given principal. A lightweight representation of
principals as Web resources supports integration of a wide range of user
management repositories. Search operations allow discovery and manipulation
of principals using human names.",
URL="http://www.rfc-editor.org/rfc/rfc3744.txt"
}

@TECHREPORT{rfc3745,
AUTHOR="D. Singer and R. N. Clark and D. Lee",
TITLE="{MIME} Type Registrations for {JPEG} 2000 {(ISO/IEC} {15444)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3745,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document serves to register and document the standard MIME types
associated with the ISO/IEC 15444 standards, commonly known as JPEG 2000
(Joint Photographic Experts Group).",
URL="http://www.rfc-editor.org/rfc/rfc3745.txt"
}

@TECHREPORT{rfc3747,
AUTHOR="Ed. H. Hazewinkel and Ed. D. Partain",
TITLE="The Differentiated Services Configuration {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3747,
MONTH=apr,
YEAR=2004,
ABSTRACT="This memo describes a MIB module that provides a conceptual layer between
high-level network-wide policy definitions that effect configuration of the
Differentiated Services (diffserv) subsystem and the instance-specific
information that would include such details as the parameters for all the
queues associated with each interface in a system. This essentially
provides an interface for configuring differentiated services at a
conceptually higher layer than that of the Differentiated Services MIB.",
URL="http://www.rfc-editor.org/rfc/rfc3747.txt"
}

@TECHREPORT{rfc3748,
AUTHOR="B. Aboba and L. Blunk and J. Vollbrecht and J. Carlson and Ed. H. Levkowetz",
TITLE="Extensible Authentication Protocol {(EAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3748,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document defines the Extensible Authentication Protocol (EAP), an
authentication framework which supports multiple authentication methods.
EAP typically runs directly over data link layers such as Point-to-Point
Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own
support for duplicate elimination and retransmission, but is reliant on
lower layer ordering guarantees. Fragmentation is not supported within EAP
itself; however, individual EAP methods may support this.",
URL="http://www.rfc-editor.org/rfc/rfc3748.txt"
}

@TECHREPORT{rfc3750,
AUTHOR="C. Huitema and R. Austein and S. Satapati and R. {van der Pol}",
TITLE="Unmanaged Networks {IPv6} Transition Scenarios",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3750,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document defines the scenarios in which IPv6 transition mechanisms are
to be used in unmanaged networks. In order to evaluate the suitability of
these mechanisms, we need to define the scenarios in which these mechanisms
have to be used. One specific scope is the unmanaged network, which
typically corresponds to a home or small office network. The scenarios are
specific to a single subnet, and are defined in terms of IP connectivity
supported by the gateway and the Internet Service Provider (ISP). We first
examine the generic requirements of four classes of applications: local,
client, peer to peer and server. Then, for each scenario, we infer
transition requirements by analyzing the needs for smooth migration of
applications from IPv4 to IPv6.",
URL="http://www.rfc-editor.org/rfc/rfc3750.txt"
}

@TECHREPORT{rfc3752,
AUTHOR="A. Barbir and E. Burger and R. Chen and S. McHenry and H. Orman and R.
Penno",
TITLE="Open Pluggable Edge Services {(OPES)} Use Cases and Deployment Scenarios",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3752,
MONTH=apr,
YEAR=2004,
ABSTRACT="This memo provides a discussion of use cases and deployment scenarios for
Open Pluggable Edge Services (OPES). The work examines services that could
be performed to requests and/or responses.",
URL="http://www.rfc-editor.org/rfc/rfc3752.txt"
}

@TECHREPORT{rfc3754,
AUTHOR="R. Bless and Univ. {of Karlsruhe} and K. Wehrle and Univ. {of Tuebingen}",
TITLE="{IP} Multicast in Differentiated Services {(DS)} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3754,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document discusses the problems of IP Multicast use in Differentiated
Services (DS) networks, expanding on the discussion in RFC 2475 (An
Architecture of Differentiated Services). It also suggests possible
solutions to these problems, describes a potential implementation model,
and presents simulation results.",
URL="http://www.rfc-editor.org/rfc/rfc3754.txt"
}

@TECHREPORT{rfc3755,
AUTHOR="S. Weiler",
TITLE="Legacy Resolver Compatibility for Delegation Signer {(DS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3755,
MONTH=may,
YEAR=2004,
ABSTRACT="As the DNS Security (DNSSEC) specifications have evolved, the syntax and
semantics of the DNSSEC resource records (RRs) have changed. Many deployed
nameservers understand variants of these semantics. Dangerous interactions
can occur when a resolver that understands an earlier version of these
semantics queries an authoritative server that understands the new
delegation signer semantics, including at least one failure scenario that
will cause an unsecured zone to be unresolvable. This document changes the
type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid
those interactions.",
URL="http://www.rfc-editor.org/rfc/rfc3755.txt"
}

@TECHREPORT{rfc3756,
AUTHOR="Ed. P. Nikander and J. Kempf and E. Nordmark",
TITLE="{IPv6} Neighbor Discovery {(ND)} Trust Models and Threats",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3756,
MONTH=may,
YEAR=2004,
ABSTRACT="The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and
Address Autoconfiguration mechanisms may be protected with IPsec
Authentication Header (AH). However, the current specifications limit the
security solutions to manual keying due to practical problems faced with
automatic key management. This document specifies three different trust
models and discusses the threats pertinent to IPv6 Neighbor Discovery. The
purpose of this discussion is to define the requirements for Securing IPv6
Neighbor Discovery.",
URL="http://www.rfc-editor.org/rfc/rfc3756.txt"
}

@TECHREPORT{rfc3757,
AUTHOR="O. Kolkman and J. Schlyter and E. Lewis",
TITLE="Domain Name System {KEY} {(DNSKEY)} Resource Record {(RR)} Secure Entry
Point {(SEP)} Flag",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3757,
MONTH=apr,
YEAR=2004,
ABSTRACT="With the Delegation Signer (DS) resource record (RR), the concept of a
public key acting as a secure entry point (SEP) has been introduced. During
exchanges of public keys with the parent there is a need to differentiate
SEP keys from other public keys in the Domain Name System KEY (DNSKEY)
resource record set. A flag bit in the DNSKEY RR is defined to indicate
that DNSKEY is to be used as a SEP. The flag bit is intended to assist in
operational procedures to correctly generate DS resource records, or to
indicate what DNSKEYs are intended for static configuration. The flag bit
is not to be used in the DNS verification protocol. This document updates
RFC 2535 and RFC 3755.",
URL="http://www.rfc-editor.org/rfc/rfc3757.txt"
}

@TECHREPORT{rfc3758,
AUTHOR="R S Stewart and M. Ramalho and Q. Xie and M. Tuexen and Univ. {of Applied
Sciences Muenster} and P. Conrad",
TITLE="Stream Control Transmission Protocol {(SCTP)} Partial Reliability Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3758,
MONTH=may,
YEAR=2004,
ABSTRACT="This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it
should move the cumulative ack point forward. When both sides of an SCTP
association support this extension, it can be used by an SCTP
implementation to provide partially reliable data transmission service to
an upper layer protocol. This memo describes the protocol extensions, which
consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN
chunk type, and provides one example of a partially reliable service that
can be provided to the upper layer via this mechanism.",
URL="http://www.rfc-editor.org/rfc/rfc3758.txt"
}

@TECHREPORT{rfc3759,
AUTHOR="L-e. Jonsson",
TITLE="{RObust} Header Compression {(ROHC):} Terminology and Channel Mapping
Examples",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3759,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document aims to clarify terms and concepts presented in RFC 3095. RFC
3095 defines a Proposed Standard framework with profiles for RObust Header
Compression (ROHC). The standard introduces various concepts which might be
difficult to understand and especially to relate correctly to the
surrounding environments where header compression may be used. This
document aims at clarifying these aspects of ROHC, discussing terms such as
ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how
these terms relate to other terms, like network elements and IP interfaces,
commonly used, for example, when addressing MIB issues.",
URL="http://www.rfc-editor.org/rfc/rfc3759.txt"
}

@TECHREPORT{rfc3760,
AUTHOR="D. Gustafson and M. Just and M. Nystrom",
TITLE="Securely Available Credentials {(SACRED)} - Credential Server Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3760,
MONTH=apr,
YEAR=2004,
ABSTRACT="As the number, and more particularly the number of different types, of
devices connecting to the Internet increases, credential mobility becomes
an issue for IETF standardization. This document responds to the
requirements on protocols for secure exchange of credentials listed in RFC
3157, by presenting an abstract protocol framework.",
URL="http://www.rfc-editor.org/rfc/rfc3760.txt"
}

@TECHREPORT{rfc3761,
AUTHOR="P. Faltstrom and M. Mealling",
TITLE="The {E.164} to Uniform Resource Identifiers {(URI)} Dynamic Delegation
Discovery System {(DDDS)} Application {(ENUM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3761,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document discusses the use of the Domain Name System (DNS) for storage
of E.164 numbers. More specifically, how DNS can be used for identifying
available services connected to one E.164 number. It specifically obsoletes
RFC 2916 to bring it in line with the Dynamic Delegation Discovery System
(DDDS) Application specification found in the document series specified in
RFC 3401. It is very important to note that it is impossible to read and
understand this document without reading the documents discussed in RFC
3401.",
URL="http://www.rfc-editor.org/rfc/rfc3761.txt"
}

@TECHREPORT{rfc3762,
AUTHOR="O. Levin",
TITLE="Telephone Number Mapping {(ENUM)} Service Registration for {H.323}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3762,
MONTH=apr,
YEAR=2004,
ABSTRACT="The H.323 specification defines a means for building multimedia
communication services over an arbitrary Packet Based Network, including
the Internet. This document registers a Telephone Number Mapping (ENUM)
service for H.323 according to specifications and guidelines in RFC 3761.",
URL="http://www.rfc-editor.org/rfc/rfc3762.txt"
}

@TECHREPORT{rfc3763,
AUTHOR="S. Shalunov and B. Teitelbaum",
TITLE="One-way Active Measurement Protocol {(OWAMP)} Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3763,
MONTH=apr,
YEAR=2004,
ABSTRACT="With growing availability of good time sources to network nodes, it becomes
increasingly possible to measure one-way IP performance metrics with high
precision. To do so in an interoperable manner, a common protocol for such
measurements is required. This document specifies requirements for a
one-way active measurement protocol (OWAMP) standard. The protocol can
measure one-way delay, as well as other unidirectional characteristics,
such as one-way loss.",
URL="http://www.rfc-editor.org/rfc/rfc3763.txt"
}

@TECHREPORT{rfc3764,
AUTHOR="J. Peterson",
TITLE="enumservice registration for Session Initiation Protocol {(SIP)}
{Addresses-of-Record}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3764,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document registers an Electronic Number (ENUM) service for the Session
Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761.
Specifically, this document focuses on provisioning SIP addresses-of-record
in ENUM.",
URL="http://www.rfc-editor.org/rfc/rfc3764.txt"
}

@TECHREPORT{rfc3765,
AUTHOR="G. Huston",
TITLE="{NOPEER} Community for Border Gateway Protocol {(BGP)} Route Scope Control",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3765,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document describes the use of a scope control Border Gateway Protocol
(BGP) community. This well-known advisory transitive community allows an
origin AS to specify the extent to which a specific route should be
externally propagated. In particular this community, NOPEER, allows an
origin AS to specify that a route with this attribute need not be
advertised across bilateral peer connections.",
URL="http://www.rfc-editor.org/rfc/rfc3765.txt"
}

@TECHREPORT{rfc3767,
AUTHOR="Ed. S. Farrell",
TITLE="Securely Available Credentials Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3767,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes a protocol whereby a user can acquire cryptographic
credentials (e.g., private keys, PKCS #15 structures) from a credential
server, using a workstation that has locally trusted software installed,
but with no user-specific configuration. The protocol's payloads are
described in XML. This memo also specifies a Blocks Extensible Exchange
Protocol (BEEP) profile of the protocol. Security requirements are met by
mandating support for TLS and/or DIGEST-MD5 (through BEEP).",
URL="http://www.rfc-editor.org/rfc/rfc3767.txt"
}

@TECHREPORT{rfc3768,
AUTHOR="Ed. R. Hinden",
TITLE="Virtual Router Redundancy Protocol {(VRRP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3768,
MONTH=apr,
YEAR=2004,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc3768.txt"
}

@TECHREPORT{rfc3769,
AUTHOR="S. Miyakawa and R Droms",
TITLE="Requirements for {IPv6} Prefix Delegation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3769,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes requirements for how IPv6 address prefixes should
be delegated to an IPv6 subscriber's network (or site).",
URL="http://www.rfc-editor.org/rfc/rfc3769.txt"
}

@TECHREPORT{rfc3770,
AUTHOR="R. Housley and T. E. Moore",
TITLE="Certificate Extensions and Attributes Supporting Authentication in
{Point-to-Point} Protocol {(PPP)} and Wireless Local Area Networks {(WLAN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3770,
MONTH=may,
YEAR=2004,
ABSTRACT="This document defines two EAP extended key usage values and a public key
certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).",
URL="http://www.rfc-editor.org/rfc/rfc3770.txt"
}

@TECHREPORT{rfc3771,
AUTHOR="R. Harrison and K. Zeilenga",
TITLE="The Lightweight Directory Access Protocol {(LDAP)} Intermediate Response
Message",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3771,
MONTH=apr,
YEAR=2004,
ABSTRACT="This document defines and describes the IntermediateResponse message, a
general mechanism for defining single-request/multiple-response operations
in Lightweight Directory Access Protocol (LDAP). The IntermediateResponse
message is defined in such a way that the protocol behavior of existing
LDAP operations is maintained. This message is intended to be used in
conjunction with the LDAP ExtendedRequest and ExtendedResponse to define
new single- request/multiple-response operations or in conjunction with a
control when extending existing LDAP operations in a way that requires them
to return intermediate response information.",
URL="http://www.rfc-editor.org/rfc/rfc3771.txt"
}

@TECHREPORT{rfc3772,
AUTHOR="J. Carlson and R. Winslow",
TITLE="{Point-to-Point} Protocol {(PPP)} Vendor Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3772,
MONTH=may,
YEAR=2004,
ABSTRACT="The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and
a method for negotiating the use of multi-protocol traffic over
point-to-point links. The PPP Vendor Extensions document adds
vendor-specific general-purpose Configuration Option and Code numbers. This
document extends these features to cover vendor- specific Network,
Authentication, and Control Protocols.",
URL="http://www.rfc-editor.org/rfc/rfc3772.txt"
}

@TECHREPORT{rfc3773,
AUTHOR="E. Candell",
TITLE="{High-Level} Requirements for Internet Voice Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3773,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes the high-level requirements for Internet Voice Mail
(IVM) and establishes a baseline of desired functionality against which
proposed MIME profiles for Internet Voice Messaging can be judged. IVM is
an extension of the Voice Profile for Internet Mail (VPIM) version 2
designed to support interoperability with desktop clients. Other goals for
this version of VPIM include expanded interoperability with unified
messaging systems, conformance to Internet standards, and backward
compatibility with voice messaging systems currently running in a VPIM
enabled environment. This document does not include goals that were met
fully by VPIM version 2.",
URL="http://www.rfc-editor.org/rfc/rfc3773.txt"
}

@TECHREPORT{rfc3774,
AUTHOR="Ed. E. Davies",
TITLE="{IETF} Problem Statement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3774,
MONTH=may,
YEAR=2004,
ABSTRACT="This memo summarizes perceived problems in the structure, function, and
processes of the Internet Engineering Task Force (IETF). We are attempting
to identify these problems, so that they can be addressed and corrected by
the IETF community.",
URL="http://www.rfc-editor.org/rfc/rfc3774.txt"
}

@TECHREPORT{rfc3775,
AUTHOR="D. B. Johnson and C. E. Perkins and J. Arkko",
TITLE="Mobility Support in {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3775,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document specifies a protocol which allows nodes to remain
   reachable while moving around in the IPv6 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 the mobile node's current location.  IPv6
   packets addressed to a mobile node's home address are transparently
   routed to its care-of address.  The protocol enables IPv6 nodes to
   cache the binding of a mobile node's home address with its care-of
   address, and to then send any packets destined for the mobile node
   directly to it at this care-of address.  To support this operation,
   Mobile IPv6 defines a new IPv6 protocol and a new destination option.All
IPv6 nodes, whether mobile or stationary, can communicate withmobile nodes."
}

@TECHREPORT{rfc3776,
AUTHOR="J. Arkko and V. Devarapalli and F. Dupont",
TITLE="Using {IPsec} to Protect Mobile {IPv6} Signaling Between Mobile Nodes and
Home Agents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3776,
MONTH=jun,
YEAR=2004,
ABSTRACT="Mobile IPv6 uses IPsec to protect signaling between the home agent and the
mobile node. Mobile IPv6 base document defines the main requirements these
nodes must follow. This document discusses these requirements in more
depth, illustrates the used packet formats, describes suitable
configuration procedures, and shows how implementations can process the
packets in the right order.",
URL="http://www.rfc-editor.org/rfc/rfc3776.txt"
}

@TECHREPORT{rfc3777,
AUTHOR="Ed. J. Galvin",
TITLE="{IAB} and {IESG} Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3777,
MONTH=jun,
YEAR=2004,
ABSTRACT="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.",
URL="http://www.rfc-editor.org/rfc/rfc3777.txt"
}

@TECHREPORT{rfc3779,
AUTHOR="C. Lynn and S. A. Kent and K. Seo",
TITLE="{X.509} Extensions for {IP} Addresses and {AS} Identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3779,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document defines two X.509 v3 certificate extensions. The first binds
a list of IP address blocks, or prefixes, to the subject of a certificate.
The second binds a list of autonomous system identifiers to the subject of
a certificate. These extensions may be used to convey the authorization of
the subject to use the IP addresses and autonomous system identifiers
contained in the extensions.",
URL="http://www.rfc-editor.org/rfc/rfc3779.txt"
}

@TECHREPORT{rfc3780,
AUTHOR="F. Strauss and J. Schoenwaelder",
TITLE="{SMIng} - Next Generation Structure of Management Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3780,
MONTH=may,
YEAR=2004,
ABSTRACT="This memo defines the base SMIng (Structure of Management Information, Next
Generation) language. SMIng is a data definition language that provides a
protocol-independent representation for management information. Separate
RFCs define mappings of SMIng to specific management protocols, including
SNMP.",
URL="http://www.rfc-editor.org/rfc/rfc3780.txt"
}

@TECHREPORT{rfc3781,
AUTHOR="F. Strauss and J. Schoenwaelder",
TITLE="Next Generation Structure of Management Information {(SMIng)} Mappings to
the Simple Network Management Protocol {(SNMP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3781,
MONTH=may,
YEAR=2004,
ABSTRACT="SMIng (Structure of Management Information, Next Generation) (RFC3780), is
a protocol-independent data definition language for management information.
This memo defines an SMIng language extension that specifies the mapping of
SMIng definitions of identities, classes, and their attributes and events
to dedicated definitions of nodes, scalar objects, tables and columnar
objects, and notifications, for application to the SNMP management
framework.",
URL="http://www.rfc-editor.org/rfc/rfc3781.txt"
}

@TECHREPORT{rfc3782,
AUTHOR="S. Floyd and T. Henderson and Andrei Gurtov",
TITLE="The {NewReno} Modification to {TCP's} Fast Recovery Algorithm",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3782,
MONTH=apr,
YEAR=2004,
ABSTRACT="The purpose of this document is to advance NewReno TCP's Fast Retransmit
and Fast Recovery algorithms in RFC 2582 from Experimental to Standards
Track status.",
URL="http://www.rfc-editor.org/rfc/rfc3782.txt"
}

@TECHREPORT{rfc3783,
AUTHOR="M. Chadalapaka and R. A. Elliott",
TITLE="Small Computer Systems Interface {(SCSI)} Command Ordering Considerations
with {iSCSI}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3783,
MONTH=may,
YEAR=2004,
ABSTRACT="Internet Small Computer Systems Interface (iSCSI) is a Small Computer
Systems Interface (SCSI) transport protocol designed to run on top of TCP.
The iSCSI session abstraction is equivalent to the classic SCSI I\_T nexus,
which represents the logical relationship between an Initiator and a Target
(I and T) required in order to communicate via the SCSI family of
protocols. The iSCSI session provides an ordered command delivery from the
SCSI initiator to the SCSI target. This document goes into the design
considerations that led to the iSCSI session model as it is defined today,
relates the SCSI command ordering features defined in T10 specifications to
the iSCSI concepts, and finally provides guidance to system designers on
how true command ordering solutions can be built based on iSCSI.",
URL="http://www.rfc-editor.org/rfc/rfc3783.txt"
}

@TECHREPORT{rfc3784,
AUTHOR="H. Smit and T. Li",
TITLE="Intermediate System to Intermediate System {(IS-IS)} Extensions for Traffic
Engineering {(TE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3784,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes extensions to the Intermediate System to
Intermediate System (IS-IS) protocol to support Traffic Engineering (TE).
This document extends the IS-IS protocol by specifying new information that
an Intermediate System (router) can place in Link State Protocol (LSP) Data
Units. This information describes additional details regarding the state of
the network that are useful for traffic engineering computations.",
URL="http://www.rfc-editor.org/rfc/rfc3784.txt"
}

@TECHREPORT{rfc3785,
AUTHOR="F. Le Faucheur and R. Uppili and A. Vedrenne and P. Merckx and Thomas 
Telkamp",
TITLE="Use of Interior Gateway Protocol {(IGP)} Metric as a second {MPLS} Traffic
Engineering {(TE)} Metric",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3785,
MONTH=may,
YEAR=2004,
ABSTRACT="This document describes a common practice on how the existing metric of
Interior Gateway Protocols (IGP) can be used as an alternative metric to
the Traffic Engineering (TE) metric for Constraint Based Routing of
MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This
effectively results in the ability to perform Constraint Based Routing with
optimization of one metric (e.g., link bandwidth) for some Traffic
Engineering tunnels (e.g., Data Trunks) while optimizing another metric
(e.g., propagation delay) for some other tunnels with different
requirements (e.g., Voice Trunks). No protocol extensions or modifications
are required. This text documents current router implementations and
deployment practices.",
URL="http://www.rfc-editor.org/rfc/rfc3785.txt"
}

@TECHREPORT{rfc3786,
AUTHOR="A. Hermelin and S. Previdi and M. Shand",
TITLE="Extending the Number of Intermediate System to Intermediate System
{(IS-IS)} Link State {PDU} {(LSP)} Fragments Beyond the 256 Limit",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3786,
MONTH=may,
YEAR=2004,
ABSTRACT="This document describes a mechanism that allows a system to originate more
than 256 Link State PDU (LSP) fragments, a limit set by the original
Intermediate System to Intermediate System (IS-IS) Routing protocol, as
described in ISO/IEC 10589. This mechanism can be used in IP-only,
OSI-only, and dual routers.",
URL="http://www.rfc-editor.org/rfc/rfc3786.txt"
}

@TECHREPORT{rfc3787,
AUTHOR="Ed. J. Parker",
TITLE="Recommendations for Interoperable {IP} Networks using Intermediate System
to Intermediate System {(IS-IS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3787,
MONTH=may,
YEAR=2004,
ABSTRACT="This document discusses a number of differences between the Intermediate
System to Intermediate System (IS-IS) protocol used to route IP traffic as
described in RFC 1195 and the protocol as it is deployed today. These
differences are discussed as a service to those implementing, testing, and
deploying the IS-IS Protocol to route IP traffic. A companion document
describes the differences between the protocol described in ISO 10589 and
current practice.",
URL="http://www.rfc-editor.org/rfc/rfc3787.txt"
}

@TECHREPORT{rfc3788,
AUTHOR="J. Loughney and Ed. M. Tuexen and Univ. {of Applied Sciences Muenster} and
J. Pastor-Balbas",
TITLE="Security Considerations for Signaling Transport {(SIGTRAN)} Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3788,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document discusses how Transport Layer Security (TLS) and IPsec can be
used to secure communication for SIGTRAN protocols. The main goal is to
recommend the minimum security means that a SIGTRAN node must implement in
order to attain secured communication. The support of IPsec is mandatory
for all nodes running SIGTRAN protocols. TLS support is optional.",
URL="http://www.rfc-editor.org/rfc/rfc3788.txt"
}

@TECHREPORT{rfc3789,
AUTHOR="I. I. P. Nesser and Ed. A. Bergstrom",
TITLE="Introduction to the Survey of {IPv4} Addresses in Currently Deployed {IETF}
Standards Track and Experimental Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3789,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document is a general overview and introduction to the v6ops IETF
workgroup project of documenting all usage of IPv4 addresses in IETF
standards track and experimental RFCs. It is broken into seven documents
conforming to the current IETF areas. It also describes the methodology
used during documentation, which types of RFCs have been documented, and
provides a concatenated summary of results.",
URL="http://www.rfc-editor.org/rfc/rfc3789.txt"
}

@TECHREPORT{rfc3790,
AUTHOR="Ed. C. Mickles and I. I. P. Nesser",
TITLE="Survey of {IPv4} Addresses in Currently Deployed {IETF} Internet Area
Standards Track and Experimental Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3790,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document seeks to document all usage of IPv4 addresses in currently
deployed IETF Internet Area documented standards. In order to successfully
transition from an all IPv4 Internet to an all IPv6 Internet, many interim
steps will be taken. One of these steps is the evolution of current
protocols that have IPv4 dependencies. It is hoped that these protocols
(and their implementations) will be redesigned to be network address
independent, but failing that will at least dually support IPv4 and IPv6.
To this end, all Standards (Full, Draft, and Proposed) as well as
Experimental RFCs will be surveyed and any dependencies will be documented.",
URL="http://www.rfc-editor.org/rfc/rfc3790.txt"
}

@TECHREPORT{rfc3791,
AUTHOR="C. Olvera and I. I. P. Nesser",
TITLE="Survey of {IPv4} Addresses in Currently Deployed {IETF} Routing Area
Standards Track and Experimental Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3791,
MONTH=jun,
YEAR=2004,
ABSTRACT="This investigation work seeks to document all usage of IPv4 addresses in
currently deployed IETF Routing Area documented standards. In order to
successfully transition from an all IPv4 Internet to an all IPv6 Internet,
many interim steps will be taken. One of these steps is the evolution of
current protocols that have IPv4 dependencies. It is hoped that these
protocols (and their implementations) will be redesigned to be network
address independent, but failing that will at least dually support IPv4 and
IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as
Experimental RFCs will be surveyed and any dependencies will be documented.",
URL="http://www.rfc-editor.org/rfc/rfc3791.txt"
}

@TECHREPORT{rfc3792,
AUTHOR="I. I. P. Nesser and Ed. A. Bergstrom",
TITLE="Survey of {IPv4} Addresses in Currently Deployed {IETF} Security Area
Standards Track and Experimental Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3792,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document seeks to document all usage of IPv4 addresses in currently
deployed IETF Security Area documented standards. In order to successfully
transition from an all IPv4 Internet to an all IPv6 Internet, many interim
steps will be taken. One of these steps is the evolution of current
protocols that have IPv4 dependencies. It is hoped that these protocols
(and their implementations) will be redesigned to be network address
independent, but failing that will at least dually support IPv4 and IPv6.
To this end, all Standards (Full, Draft, and Proposed) as well as
Experimental RFCs will be surveyed and any dependencies will be documented.",
URL="http://www.rfc-editor.org/rfc/rfc3792.txt"
}

@TECHREPORT{rfc3793,
AUTHOR="I. I. P. Nesser and Ed. A. Bergstrom",
TITLE="Survey of {IPv4} Addresses in Currently Deployed {IETF} {Sub-IP} Area
Standards Track and Experimental Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3793,
MONTH=may,
YEAR=2004,
ABSTRACT="This document seeks to document all usage of IPv4 addresses in currently
deployed IETF Sub-IP Area documented standards. In order to successfully
transition from an all IPv4 Internet to an all IPv6 Internet, many interim
steps will be taken. One of these steps is the evolution of current
protocols that have IPv4 dependencies. It is hoped that these protocols
(and their implementations) will be redesigned to be network address
independent, but failing that will at least dually support IPv4 and IPv6.
To this end, all Standards (Full, Draft, and Proposed) as well as
Experimental RFCs will be surveyed and any dependencies will be documented.",
URL="http://www.rfc-editor.org/rfc/rfc3793.txt"
}

@TECHREPORT{rfc3794,
AUTHOR="I. I. P. Nesser and Ed. A. Bergstrom",
TITLE="Survey of {IPv4} Addresses in Currently Deployed {IETF} Transport Area
Standards Track and Experimental Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3794,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document seeks to document all usage of IPv4 addresses in currently
deployed IETF Transport Area documented standards. In order to successfully
transition from an all IPv4 Internet to an all IPv6 Internet, many interim
steps will be taken. One of these steps is the evolution of current
protocols that have IPv4 dependencies. It is hoped that these protocols
(and their implementations) will be redesigned to be network address
independent, but failing that will at least dually support IPv4 and IPv6.
To this end, all Standards (Full, Draft, and Proposed) as well as
Experimental RFCs will be surveyed and any dependencies will be documented.",
URL="http://www.rfc-editor.org/rfc/rfc3794.txt"
}

@TECHREPORT{rfc3795,
AUTHOR="Rute C. Sofia and I. I. P. Nesser",
TITLE="Survey of {IPv4} Addresses in Currently Deployed {IETF} Application Area
Standards Track and Experimental Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3795,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes IPv4 addressing dependencies in an attempt to
clarify the necessary steps in re-designing and re-implementing
specifications to become network address independent, or at least, to
dually support IPv4 and IPv6. This transition requires several interim
steps, one of them being the evolution of current IPv4 dependent
specifications to a format independent of the type of IP addressing schema
used. Hence, it is hoped that specifications will be re-designed and
re-implemented to become network address independent, or at least to dually
support IPv4 and IPv6.",
URL="http://www.rfc-editor.org/rfc/rfc3795.txt"
}

@TECHREPORT{rfc3796,
AUTHOR="I. I. P. Nesser and Ed. A. Bergstrom",
TITLE="Survey of {IPv4} Addresses in Currently Deployed {IETF} Operations \&
Management Area Standards Track and Experimental Documents",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3796,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document seeks to record all usage of IPv4 addresses in currently
deployed IETF Operations \& Management Area accepted standards. In order to
successfully transition from an all IPv4 Internet to an all IPv6 Internet,
many interim steps will be taken. One of these steps is the evolution of
current protocols that have IPv4 dependencies. It is hoped that these
protocols (and their implementations) will be redesigned to be network
address independent, but failing that will at least dually support IPv4 and
IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as
Experimental RFCs, will be surveyed and any dependencies will be
documented.",
URL="http://www.rfc-editor.org/rfc/rfc3796.txt"
}

@TECHREPORT{rfc3797,
AUTHOR="D. Eastlake 3rd",
TITLE="Publicly Verifiable Nominations Committee {(NomCom)} Random Selection",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3797,
MONTH=jun,
YEAR=2004,
ABSTRACT="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 (NomCom) from the pool of eligible volunteers is used. Similar
techniques would be applicable to other cases.",
URL="http://www.rfc-editor.org/rfc/rfc3797.txt"
}

@TECHREPORT{rfc3798,
AUTHOR="Ed. T. Hansen and Ed. G. Vaudreuil",
TITLE="Message Disposition Notification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3798,
MONTH=may,
YEAR=2004,
ABSTRACT="This memo defines a MIME content-type that may be used by a mail user agent
(MUA) or electronic mail gateway to report the disposition of a message
after it has been successfully 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 LAN-based systems, and often referred to as read
receipts, acknowledgements, or receipt notifications. The intention is to
do this while respecting privacy concerns, which have often been expressed
when such functions have been discussed in the past.",
URL="http://www.rfc-editor.org/rfc/rfc3798.txt"
}

@TECHREPORT{rfc3801,
AUTHOR="G. M. Vaudreuil and G. Parsons",
TITLE="Voice Profile for Internet Mail - version 2 {(VPIMv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3801,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document specifies a restricted profile of the Internet multimedia
messaging protocols for use between voice processing server platforms. The
profile is referred to as the Voice Profile for Internet Mail (VPIM) in
this document. These platforms have historically been special-purpose
computers and often do not have the same facilities normally associated
with a traditional Internet Email-capable computer. As a result, VPIM also
specifies additional functionality, as it is needed. This profile is
intended to specify the minimum common set of features to allow
interworking between conforming systems.",
URL="http://www.rfc-editor.org/rfc/rfc3801.txt"
}

@TECHREPORT{rfc3802,
AUTHOR="G. M. Vaudreuil and G. Parsons",
TITLE="Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation
{(ADPCM)} {MIME} Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3802,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes the registration of the MIME sub-type
audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality
audio. This audio encoding is defined by the ITU-T in Recommendation G.726.",
URL="http://www.rfc-editor.org/rfc/rfc3802.txt"
}

@TECHREPORT{rfc3803,
AUTHOR="G. M. Vaudreuil and G. Parsons",
TITLE="Content Duration {MIME} Header Definition",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3803,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes the MIME header Content-Duration that is intended
for use with any time varying media content (typically audio/* or video/*).",
URL="http://www.rfc-editor.org/rfc/rfc3803.txt"
}

@TECHREPORT{rfc3804,
AUTHOR="G. Parsons",
TITLE="Voice Profile for Internet Mail {(VPIM)} Addressing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3804,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document lists the various Voice Profile for Internet Mail (VPIM)
email address formats that are currently in common use and defines several
new address formats for special case usage. Requirements are imposed on the
formats of addresses used in VPIM submission mode.",
URL="http://www.rfc-editor.org/rfc/rfc3804.txt"
}

@TECHREPORT{rfc3805,
AUTHOR="R. Bergman and H. Lewis and I. McDonald",
TITLE="Printer {MIB} v2",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3805,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document provides definitions of models and manageable objects for
printing environments. The objects included in this MIB apply to physical,
as well as logical entities within a printing device. This document
obsoletes RFC 1759.",
URL="http://www.rfc-editor.org/rfc/rfc3805.txt"
}

@TECHREPORT{rfc3806,
AUTHOR="R. Bergman and H. Lewis and I. McDonald",
TITLE="Printer Finishing {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3806,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document defines a MIB module for the management of printer finishing
device subunits. The finishing device subunits applicable to this MIB are
an integral part of the Printer System. This MIB applies only to a Finisher
Device that is connected to a Printer System.",
URL="http://www.rfc-editor.org/rfc/rfc3806.txt"
}

@TECHREPORT{rfc3807,
AUTHOR="E. Weilandt and N. Khanchandani and S. V. Rao",
TITLE="{V5.2-User} Adaptation Layer {(V5UA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3807,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document defines a mechanism for the backhauling of V5.2 messages over
IP using the Stream Control Transmission Protocol (SCTP). This protocol may
be used between a Signaling Gateway (SG) and a Media Gateway controller
(MGC). It is assumed that the SG receives V5.2 signaling over a standard
V5.2 interface.",
URL="http://www.rfc-editor.org/rfc/rfc3807.txt"
}

@TECHREPORT{rfc3808,
AUTHOR="I. McDonald",
TITLE="{IANA} Charset {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3808,
MONTH=jun,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. This IANA
Charset MIB is now an IANA registry. In particular, a single textual
convention 'IANACharset' is defined that may be used to specify charset
labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC
3805). 'IANACharset' was originally defined (and mis-named) as
'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C,
that may be used by IANA to regenerate this IANA Charset MIB, when future
charsets are registered in accordance with the IANA Charset Registration
Procedures (RFC 2978).",
URL="http://www.rfc-editor.org/rfc/rfc3808.txt"
}

@TECHREPORT{rfc3809,
AUTHOR="Ed. A. Nagarajan",
TITLE="Generic Requirements for Provider Provisioned Virtual Private Networks
{(PPVPN)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3809,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes generic requirements for Provider Provisioned
Virtual Private Networks (PPVPN). The requirements are categorized into
service requirements, provider requirements and engineering requirements.
These requirements are not specific to any particular type of PPVPN
technology, but rather apply to all PPVPN technologies. All PPVPN
technologies are expected to meet the umbrella set of requirements
described in this document.",
URL="http://www.rfc-editor.org/rfc/rfc3809.txt"
}

@TECHREPORT{rfc3810,
AUTHOR="Ed. R. Vida and Ed. L. Costa",
TITLE="Multicast Listener Discovery Version 2 {(MLDv2)} for {IPv6}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3810,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document updates RFC 2710, and it specifies Version 2 of the Multicast
Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to
discover the presence of multicast listeners on directly attached links,
and to discover which multicast addresses are of interest to those
neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2
adds the ability for a node to report interest in listening to packets with
a particular multicast address only from specific source addresses or from
all sources except for specific source addresses.",
URL="http://www.rfc-editor.org/rfc/rfc3810.txt"
}

@TECHREPORT{rfc3811,
AUTHOR="Ed. T. Nadeau and Ed. J. Cucchiara",
TITLE="Definitions of Textual Conventions {(TCs)} for Multiprotocol Label
Switching {(MPLS)} Management",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3811,
MONTH=jun,
YEAR=2004,
ABSTRACT="This memo defines a Management Information Base (MIB) module which contains
Textual Conventions to represent commonly used Multiprotocol Label
Switching (MPLS) management information. The intent is that these TEXTUAL
CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules
that would otherwise define their own representations.",
URL="http://www.rfc-editor.org/rfc/rfc3811.txt"
}

@TECHREPORT{rfc3812,
AUTHOR="C. Srinivasan and A. Viswanathan and T. Nadeau",
TITLE="Multiprotocol Label Switching {(MPLS)} Traffic Engineering {(TE)}
Management Information Base {(MIB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3812,
MONTH=jun,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes managed objects for Multiprotocol Label Switching
(MPLS) based traffic engineering (TE).",
URL="http://www.rfc-editor.org/rfc/rfc3812.txt"
}

@TECHREPORT{rfc3813,
AUTHOR="C. Srinivasan and A. Viswanathan and T. Nadeau",
TITLE="Multiprotocol Label Switching {(MPLS)} Label Switching Router {(LSR)}
Management Information Base {(MIB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3813,
MONTH=jun,
YEAR=2004,
ABSTRACT="This memo defines an portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes managed objects to configure and/or monitor a
Multiprotocol Label Switching (MPLS) Label Switching Router (LSR).",
URL="http://www.rfc-editor.org/rfc/rfc3813.txt"
}

@TECHREPORT{rfc3814,
AUTHOR="T. Nadeau and C. Srinivasan and A. Viswanathan",
TITLE="Multiprotocol Label Switching {(MPLS)} Forwarding Equivalence Class To Next
Hop Label Forwarding Entry {(FEC-To-NHLFE)} Management Information Base
{(MIB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3814,
MONTH=jun,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes managed objects for defining, configuring, and
monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding
Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol
Label Switching (MPLS).",
URL="http://www.rfc-editor.org/rfc/rfc3814.txt"
}

@TECHREPORT{rfc3815,
AUTHOR="J. Cucchiara and H. Sjostrand and J. Luciani",
TITLE="Definitions of Managed Objects for the Multiprotocol Label Switching
{(MPLS),} Label Distribution Protocol {(LDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3815,
MONTH=jun,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes managed objects for the Multiprotocol Label
Switching, Label Distribution Protocol (LDP).",
URL="http://www.rfc-editor.org/rfc/rfc3815.txt"
}

@TECHREPORT{rfc3816,
AUTHOR="Juergen Quittek and M. Stiemerling and Hannes Hartenstein",
TITLE="Definitions of Managed Objects for {RObust} Header Compression {(ROHC)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3816,
MONTH=jun,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes a set of managed objects that allow monitoring of
running instances of RObust Header Compression (ROHC). The managed objects
defined in this memo are grouped into three MIB modules. The ROHC-MIB
module defines managed objects shared by all ROHC profiles, the
ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC
uncompressed profile, the ROHC-RTP-MIB module defines managed objects
specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC
UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security
Payload) profile, and the ROHC LLA (Link Layer Assisted) profile.",
URL="http://www.rfc-editor.org/rfc/rfc3816.txt"
}

@TECHREPORT{rfc3817,
AUTHOR="W. Townsley and R. {da Silva}",
TITLE="Layer 2 Tunneling Protocol {(L2TP)} Active Discovery Relay for {PPP} over
Ethernet {(PPPoE)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3817,
MONTH=jun,
YEAR=2004,
ABSTRACT="The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. Layer Two
Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across
an intervening packet-switched network. And yet a third protocol, PPP over
Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP
packets over Ethernet.",
URL="http://www.rfc-editor.org/rfc/rfc3817.txt"
}

@TECHREPORT{rfc3818,
AUTHOR="V. Schryver",
TITLE="{IANA} Considerations for the {Point-to-Point} Protocol {(PPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3818,
MONTH=jun,
YEAR=2004,
ABSTRACT="The charter of the Point-to-Point Protocol (PPP) Extensions working group
(pppext) includes the responsibility to actively advance PPP's most useful
extensions to full standard, while defending against further enhancements
of questionable value. In support of that charter, the allocation of PPP
protocol and other assigned numbers will no longer be first come first
served.",
URL="http://www.rfc-editor.org/rfc/rfc3818.txt"
}

@TECHREPORT{rfc3819,
AUTHOR="Ed. P. Karn and C. Bormann and G. Fairhurst and D. Grossman and R. Ludwig
and J. Mahdavi and Gabriel E. Montenegro and J. Touch",
TITLE="Advice for Internet Subnetwork Designers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3819,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document provides advice to the designers of digital communication
equipment, link-layer protocols, and packet-switched local networks
(collectively referred to as subnetworks), who wish to support the Internet
protocols but may be unfamiliar with the Internet architecture and the
implications of their design choices on the performance and efficiency of
the Internet.",
URL="http://www.rfc-editor.org/rfc/rfc3819.txt"
}

@TECHREPORT{rfc3820,
AUTHOR="S. Tuecke and V. Welch and D. Engert and L. Pearlman and M. Thompson",
TITLE="Internet {X.509} Public Key Infrastructure {(PKI)} Proxy Certificate
Profile",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3820,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document forms a certificate profile for Proxy Certificates, based on
X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280,
for use in the Internet. The term Proxy Certificate is used to describe a
certificate that is derived from, and signed by, a normal X.509 Public Key
End Entity Certificate or by another Proxy Certificate for the purpose of
providing restricted proxying and delegation within a PKI based
authentication system.",
URL="http://www.rfc-editor.org/rfc/rfc3820.txt"
}

@TECHREPORT{rfc3821,
AUTHOR="M. Rajagopal and E. Rodriguez and R. A. Weber",
TITLE="Fibre Channel Over {TCP/IP} {(FCIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3821,
MONTH=jul,
YEAR=2004,
ABSTRACT="Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the
interconnection of islands of Fibre Channel storage area networks over
IP-based networks to form a unified storage area network in a single Fibre
Channel fabric. FCIP relies on IP-based network services to provide the
connectivity between the storage area network islands over local area
networks, metropolitan area networks, or wide area networks.",
URL="http://www.rfc-editor.org/rfc/rfc3821.txt"
}

@TECHREPORT{rfc3822,
AUTHOR="D. Peterson",
TITLE="Finding Fibre Channel over {TCP/IP} {(FCIP)} Entities Using Service
Location Protocol version 2 {(SLPv2)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3822,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document defines the use of Service Location Protocol version 2
(SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities.",
URL="http://www.rfc-editor.org/rfc/rfc3822.txt"
}

@TECHREPORT{rfc3823,
AUTHOR="B. Kovitz",
TITLE="{MIME} Media Type for the Systems Biology Markup Language {(SBML)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3823,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document registers the MIME sub-type application/sbml+xml, a media
type for SBML, the Systems Biology Markup Language. SBML is defined by The
SBML Team at the California Institute of Technology and interested members
of the systems biology community.",
URL="http://www.rfc-editor.org/rfc/rfc3823.txt"
}

@TECHREPORT{rfc3824,
AUTHOR="J. Peterson and H. N. Liu and J. Yu and B. Campbell",
TITLE="Using {E.164} numbers with the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3824,
MONTH=jun,
YEAR=2004,
ABSTRACT="There are a number of contexts in which telephone numbers are employed by
Session Initiation Protocol (SIP) applications, many of which can be
addressed by ENUM. Although SIP was one of the primary applications for
which ENUM was created, there is nevertheless a need to define procedures
for integrating ENUM with SIP implementations. This document illustrates
how the two protocols might work in concert, and clarifies the authoring
and processing of ENUM records for SIP applications. It also provides
guidelines for instances in which ENUM, for whatever reason, cannot be used
to resolve a telephone number.",
URL="http://www.rfc-editor.org/rfc/rfc3824.txt"
}

@TECHREPORT{rfc3825,
AUTHOR="J. Polk and J. Schnizlein and M. Linsner",
TITLE="Dynamic Host Configuration Protocol Option for Coordinate-based Location
Configuration Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3825,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document specifies a Dynamic Host Configuration Protocol Option for
the coordinate-based geographic location of the client. The Location
Configuration Information (LCI) includes latitude, longitude, and altitude,
with resolution indicators for each. The reference datum for these values
is also included.",
URL="http://www.rfc-editor.org/rfc/rfc3825.txt"
}

@TECHREPORT{rfc3826,
AUTHOR="Uri Blumenthal and F. Maino and K. McCloghrie",
TITLE="The Advanced Encryption Standard {(AES)} Cipher Algorithm in the {SNMP}
User-based Security Model",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3826,
MONTH=jun,
YEAR=2004,
ABSTRACT="This document describes a symmetric encryption protocol that supplements
the protocols described in the User-based Security Model (USM), which is a
Security Subsystem for version 3 of the Simple Network Management Protocol
for use in the SNMP Architecture. The symmetric encryption protocol
described in this document is based on the Advanced Encryption Standard
(AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size
of 128 bits.",
URL="http://www.rfc-editor.org/rfc/rfc3826.txt"
}

@TECHREPORT{rfc3827,
AUTHOR="K. Sarcar",
TITLE="Additional Snoop Datalink Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3827,
MONTH=jun,
YEAR=2004,
ABSTRACT="The snoop file format provides a way to store and exchange datalink layer
packet traces. This document describes extensions to this file format to
support new media.",
URL="http://www.rfc-editor.org/rfc/rfc3827.txt"
}

@TECHREPORT{rfc3828,
AUTHOR="Lars-Åke Larzon and M. Degermark and S. Pink and Ed. L-E. Jonsson and Ed.
G. Fairhurst",
TITLE="The Lightweight User Datagram Protocol {(UDP-Lite)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3828,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document describes the Lightweight User Datagram Protocol (UDP- Lite),
which is similar to the User Datagram Protocol (UDP) (RFC 768), but can
also serve applications in error-prone network environments that prefer to
have partially damaged payloads delivered rather than discarded. If this
feature is not used, UDP-Lite is semantically identical to UDP.",
URL="http://www.rfc-editor.org/rfc/rfc3828.txt"
}

@TECHREPORT{rfc3829,
AUTHOR="R. Weltman and M. Smith and M. Wahl",
TITLE="Lightweight Directory Access Protocol {(LDAP)} Authorization Identity
Request and Response Controls",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3829,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document extends the Lightweight Directory Access Protocol (LDAP) bind
operation with a mechanism for requesting and returning the authorization
identity it establishes. Specifically, this document defines the
Authorization Identity Request and Response controls for use with the Bind
operation.",
URL="http://www.rfc-editor.org/rfc/rfc3829.txt"
}

@TECHREPORT{rfc3830,
AUTHOR="J. Arkko and E. Carrara and F. Lindholm and M. Naslund and K. Norrman",
TITLE="{MIKEY:} Multimedia Internet {KEYing}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3830,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document describes a key management scheme that can be used for
real-time applications (both for peer-to-peer communication and group
communication). In particular, its use to support the Secure Real- time
Transport Protocol is described in detail.",
URL="http://www.rfc-editor.org/rfc/rfc3830.txt"
}

@TECHREPORT{rfc3831,
AUTHOR="C. DeSanti",
TITLE="Transmission of {IPv6} Packets over Fibre Channel",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3831,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document specifies the way of encapsulating IPv6 packets over Fibre
Channel, and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on Fibre Channel networks.",
URL="http://www.rfc-editor.org/rfc/rfc3831.txt"
}

@TECHREPORT{rfc3832,
AUTHOR="Weibin Zhao and Henning Schulzrinne and Erik Guttman and Chatschik
Bisdikian and William Jerome",
TITLE="Remote Service Discovery in the Service Location Protocol {(SLP)} via {DNS}
{SRV}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3832,
MONTH=jul,
YEAR=2004,
URL="http://www.ietf.org/rfc/rfc3832.txt"
}

@TECHREPORT{rfc3833,
AUTHOR="D. Atkins and R. Austein",
TITLE="Threat Analysis of the Domain Name System {(DNS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3833,
MONTH=aug,
YEAR=2004,
ABSTRACT="Although the DNS Security Extensions (DNSSEC) have been under development
for most of the last decade, the IETF has never written down the specific
set of threats against which DNSSEC is designed to protect. Among other
drawbacks, this cart-before-the-horse situation has made it difficult to
determine whether DNSSEC meets its design goals, since its design goals are
not well specified. This note attempts to document some of the known
threats to the DNS, and, in doing so, attempts to measure to what extent
(if any) DNSSEC is a useful tool in defending against these threats.",
URL="http://www.rfc-editor.org/rfc/rfc3833.txt"
}

@TECHREPORT{rfc3835,
AUTHOR="A. Barbir and R. Penno and R. Chen and M. Hofmann and H. Orman",
TITLE="An Architecture for Open Pluggable Edge Services {(OPES)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3835,
MONTH=aug,
YEAR=2004,
ABSTRACT="This memo defines an architecture that enables the creation of an
application service in which a data provider, a data consumer, and zero or
more application entities cooperatively implement a data stream service.",
URL="http://www.rfc-editor.org/rfc/rfc3835.txt"
}

@TECHREPORT{rfc3836,
AUTHOR="A. Beck and M. Hofmann and H. Orman and R. Penno and Andreas Terzis",
TITLE="Requirements for Open Pluggable Edge Services {(OPES)} Callout Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3836,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document specifies the requirements that the OPES (Open Pluggable Edge
Services) callout protocol must satisfy in order to support the remote
execution of OPES services. The requirements are intended to help evaluate
possible protocol candidates, as well as to guide the development of such
protocols.",
URL="http://www.rfc-editor.org/rfc/rfc3836.txt"
}

@TECHREPORT{rfc3837,
AUTHOR="A. Barbir and O. Batuner and B. Srinivas and M. Hofmann and H. Orman",
TITLE="Security Threats and Risks for Open Pluggable Edge Services {(OPES)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3837,
MONTH=aug,
YEAR=2004,
ABSTRACT="The document investigates the security threats associated with the Open
Pluggable Edge Services (OPES) and discusses the effects of security
threats on the underlying architecture. The main goal of this document is
threat discovery and analysis. The document does not specify or recommend
any solutions.",
URL="http://www.rfc-editor.org/rfc/rfc3837.txt"
}

@TECHREPORT{rfc3838,
AUTHOR="A. Barbir and O. Batuner and A. Beck and T. Chan and H. Orman",
TITLE="Policy, Authorization, and Enforcement Requirements of the Open Pluggable
Edge Services {(OPES)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3838,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document describes policy, authorization, and enforcement requirements
for the selection of the services to be applied to a given Open Pluggable
Edge Services (OPES) flow.",
URL="http://www.rfc-editor.org/rfc/rfc3838.txt"
}

@TECHREPORT{rfc3839,
AUTHOR="R. Castagno and D. Singer",
TITLE="{MIME} Type Registrations for 3rd Generation Partnership Project {(3GPP)}
Multimedia files",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3839,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document serves to register and document the standard MIME types
associated with the 3GPP multimedia file format, which is part of the
family based on the ISO Media File Format.",
URL="http://www.rfc-editor.org/rfc/rfc3839.txt"
}

@TECHREPORT{rfc3840,
AUTHOR="Jonathan Rosenberg and Paul Kyzivat and Henning Schulzrinne",
TITLE="Indicating User Agent Capabilities in the Session Initiation Protocol
{(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3840,
MONTH=aug,
YEAR=2004,
ABSTRACT="This specification defines mechanisms by which a Session Initiation
Protocol (SIP) user agent can convey its capabilities and characteristics
to other user agents and to the registrar for its domain. This information
is conveyed as parameters of the Contact header field.",
URL="http://www.rfc-editor.org/rfc/rfc3840.txt"
}

@TECHREPORT{rfc3841,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne and Paul Kyzivat",
TITLE="Caller Preferences for the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3841,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document describes a set of extensions to the Session Initiation
Protocol (SIP) which allow a caller to express preferences about request
handling in servers. These preferences include the ability to select which
Uniform Resource Identifiers (URI) a request gets routed to, and to specify
certain request handling directives in proxies and redirect servers. It
does so by defining three new request header fields, Accept-Contact,
Reject-Contact, and Request-Disposition, which specify the caller's
preferences.",
URL="http://www.rfc-editor.org/rfc/rfc3841.txt"
}

@TECHREPORT{rfc3842,
AUTHOR="R. Mahy",
TITLE="A Message Summary and Message Waiting Indication Event Package for the
Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3842,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document describes a Session Initiation Protocol (SIP) event package
to carry message waiting status and message summaries from a messaging
system to an interested User Agent.",
URL="http://www.rfc-editor.org/rfc/rfc3842.txt"
}

@TECHREPORT{rfc3843,
AUTHOR="L-e. Jonsson and G. Pelletier",
TITLE="{RObust} Header Compression {(ROHC):} A Compression Profile for {IP}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3843,
MONTH=jun,
YEAR=2004,
ABSTRACT="The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a
framework for header compression, along with compression protocols
(profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP,
and also a profile for uncompressed packet streams. However, no profile was
defined for compression of IP only, which has been identified as a missing
piece in RFC 3095. This document defines a ROHC compression profile for IP,
similar to the IP/UDP profile defined by RFC 3095, but simplified to
exclude UDP, and enhanced to compress IP header chains of arbitrary length.",
URL="http://www.rfc-editor.org/rfc/rfc3843.txt"
}

@TECHREPORT{rfc3845,
AUTHOR="Ed. J. Schlyter",
TITLE="{DNS} Security {(DNSSEC)} {NextSECure} {(NSEC)} {RDATA} Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3845,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document redefines the wire format of the Type Bit Map field in the
DNS NextSECure (NSEC) resource record RDATA format to cover the full
resource record (RR) type space.",
URL="http://www.rfc-editor.org/rfc/rfc3845.txt"
}

@TECHREPORT{rfc3846,
AUTHOR="F. Johansson and T. Johansson",
TITLE="Mobile {IPv4} Extension for Carrying Network Access Identifiers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3846,
MONTH=jun,
YEAR=2004,
ABSTRACT="When a mobile node moves between two foreign networks, it has to be
re-authenticated. If the home network has both multiple Authentication
Authorization and Accounting (AAA) servers and Home Agents (HAs) in use,
the Home AAA server may not have sufficient information to process the
re-authentication correctly (i.e., to ensure that the same HA continues to
be used). This document defines a Mobile IP extension that carries
identities for the Home AAA and HA servers in the form of Network Access
Identifiers (NAIs). The extension allows a Home Agent to pass its identity
(and that of the Home AAA server) to the mobile node, which can then pass
it on to the local AAA server when changing its point of attachment. This
extension may also be used in other situations requiring communication of a
NAI between Mobile IP nodes.",
URL="http://www.rfc-editor.org/rfc/rfc3846.txt"
}

@TECHREPORT{rfc3847,
AUTHOR="M. Shand and L. Ginsberg",
TITLE="Restart Signaling for Intermediate System to Intermediate System {(IS-IS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3847,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document describes a mechanism for a restarting router to signal to
its neighbors that it is restarting, allowing them to reestablish their
adjacencies without cycling through the down state, while still correctly
initiating database synchronization.",
URL="http://www.rfc-editor.org/rfc/rfc3847.txt"
}

@TECHREPORT{rfc3848,
AUTHOR="C. Newman",
TITLE="{ESMTP} and {LMTP} Transmission Types Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3848,
MONTH=jul,
YEAR=2004,
ABSTRACT="This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA,
LMTP, LMTPA, LMTPS, LMTPSA) for use in the with clause of a Received header
in an Internet message.",
URL="http://www.rfc-editor.org/rfc/rfc3848.txt"
}

@TECHREPORT{rfc3850,
AUTHOR="Editor B. Ramsdell",
TITLE="{Secure/Multipurpose} Internet Mail Extensions {(S/MIME)} Version {3.1}
Certificate Handling",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3850,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME
provides a method to send and receive secure MIME messages, and
certificates are an integral part of S/MIME agent processing. S/MIME agents
validate certificates as described in RFC 3280, the Internet X.509 Public
Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the
certificate processing requirements in this document as well as those in
RFC 3280.",
URL="http://www.rfc-editor.org/rfc/rfc3850.txt"
}

@TECHREPORT{rfc3851,
AUTHOR="Editor B. Ramsdell",
TITLE="{Secure/Multipurpose} Internet Mail Extensions {(S/MIME)} Version {3.1}
Message Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3851,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME)
version 3.1. S/MIME provides a consistent way to send and receive secure
MIME data. Digital signatures provide authentication, message integrity,
and non-repudiation with proof of origin. Encryption provides data
confidentiality. Compression can be used to reduce data size. This document
obsoletes RFC 2633.",
URL="http://www.rfc-editor.org/rfc/rfc3851.txt"
}

@TECHREPORT{rfc3852,
AUTHOR="R. Housley",
TITLE="Cryptographic Message Syntax {(CMS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3852,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document describes the Cryptographic Message Syntax (CMS). This syntax
is used to digitally sign, digest, authenticate, or encrypt arbitrary
message content.",
URL="http://www.rfc-editor.org/rfc/rfc3852.txt"
}

@TECHREPORT{rfc3853,
AUTHOR="J. Peterson",
TITLE="{S/MIME} Advanced Encryption Standard {(AES)} Requirement for the Session
Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3853,
MONTH=jul,
YEAR=2004,
ABSTRACT="RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite
for implementations of S/MIME in the Session Initiation Protocol (SIP).
This document updates the normative guidance of RFC 3261 to require the
Advanced Encryption Standard (AES) for S/MIME.",
URL="http://www.rfc-editor.org/rfc/rfc3853.txt"
}

@TECHREPORT{rfc3854,
AUTHOR="P. Hoffman and C. Bonatti and A. Eggen",
TITLE="Securing {X.400} Content with {Secure/Multipurpose} Internet Mail
Extensions {(S/MIME)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3854,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document describes a protocol for adding cryptographic signature and
encryption services to X.400 content with Secure/Multipurpose Internet Mail
Extensions (S/MIME).",
URL="http://www.rfc-editor.org/rfc/rfc3854.txt"
}

@TECHREPORT{rfc3855,
AUTHOR="P. Hoffman and C. Bonatti",
TITLE="Transporting {Secure/Multipurpose} Internet Mail Extensions {(S/MIME)}
Objects in {X.400}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3855,
MONTH=jul,
YEAR=2004,
ABSTRACT="This document describes protocol options for conveying objects that have
been protected using the Cryptographic Message Syntax (CMS) and
Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an
X.400 message transfer system.",
URL="http://www.rfc-editor.org/rfc/rfc3855.txt"
}

@TECHREPORT{rfc3856,
AUTHOR="J. Rosenberg",
TITLE="A Presence Event Package for the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3856,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document describes the usage of the Session Initiation Protocol (SIP)
for subscriptions and notifications of presence. Presence is defined as the
willingness and ability of a user to communicate with other users on the
network. Historically, presence has been limited to on-line and off-line
indicators; the notion of presence here is broader. Subscriptions and
notifications of presence are supported by defining an event package within
the general SIP event notification framework. This protocol is also
compliant with the Common Presence Profile (CPP) framework.",
URL="http://www.rfc-editor.org/rfc/rfc3856.txt"
}

@TECHREPORT{rfc3857,
AUTHOR="J. Rosenberg",
TITLE="A Watcher Information Event {Template-Package} for the Session Initiation
Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3857,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document defines the watcher information template-package for the
Session Initiation Protocol (SIP) event framework. Watcher information
refers to the set of users subscribed to a particular resource within a
particular event package. Watcher information changes dynamically as users
subscribe, unsubscribe, are approved, or are rejected. A user can subscribe
to this information, and therefore learn about changes to it. This event
package is a template-package because it can be applied to any event
package, including itself.",
URL="http://www.rfc-editor.org/rfc/rfc3857.txt"
}

@TECHREPORT{rfc3858,
AUTHOR="J. Rosenberg",
TITLE="An Extensible Markup Language {(XML)} Based Format for Watcher Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3858,
MONTH=aug,
YEAR=2004,
ABSTRACT="Watchers are defined as entities that request (i.e., subscribe to)
information about a resource. There is fairly complex state associated with
these subscriptions. The union of the state for all subscriptions to a
particular resource is called the watcher information for that resource.
This state is dynamic, changing as subscribers come and go. As a result, it
is possible, and indeed useful, to subscribe to the watcher information for
a particular resource. In order to enable this, a format is needed to
describe the state of watchers on a resource. This specification describes
an Extensible Markup Language (XML) document format for such state.",
URL="http://www.rfc-editor.org/rfc/rfc3858.txt"
}

@TECHREPORT{rfc3859,
AUTHOR="J. Peterson",
TITLE="Common Profile for Presence {(CPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3859,
MONTH=aug,
YEAR=2004,
ABSTRACT="At the time this document was written, numerous presence protocols were in
use (largely as components of commercial instant messaging services), and
little interoperability between services based on these protocols has been
achieved. This specification defines common semantics and data formats for
presence to facilitate the creation of gateways between presence services.",
URL="http://www.rfc-editor.org/rfc/rfc3859.txt"
}

@TECHREPORT{rfc3860,
AUTHOR="J. Peterson",
TITLE="Common Profile for Instant Messaging {(CPIM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3860,
MONTH=aug,
YEAR=2004,
ABSTRACT="At the time this document was written, numerous instant messaging protocols
were in use, and little interoperability between services based on these
protocols has been achieved. This specification defines common semantics
and data formats for instant messaging to facilitate the creation of
gateways between instant messaging services.",
URL="http://www.rfc-editor.org/rfc/rfc3860.txt"
}

@TECHREPORT{rfc3861,
AUTHOR="J. Peterson",
TITLE="Address Resolution for Instant Messaging and Presence",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3861,
MONTH=aug,
YEAR=2004,
ABSTRACT="Presence and instant messaging are defined in RFC 2778. The Common Profiles
for Presence and Instant Messaging define two Universal Resource Identifier
(URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This
document provides guidance for locating the resources associated with URIs
that employ these schemes.",
URL="http://www.rfc-editor.org/rfc/rfc3861.txt"
}

@TECHREPORT{rfc3862,
AUTHOR="G. Klyne and D. Atkins",
TITLE="Common Presence and Instant Messaging {(CPIM):} Message Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3862,
MONTH=aug,
YEAR=2004,
ABSTRACT="This memo defines the MIME content type 'Message/CPIM', a message format
for protocols that conform to the Common Profile for Instant Messaging
(CPIM) specification.",
URL="http://www.rfc-editor.org/rfc/rfc3862.txt"
}

@TECHREPORT{rfc3863,
AUTHOR="H. Sugano and S. Fujimoto and G. Klyne and A. Bateman and W. Carr and J.
Peterson",
TITLE="Presence Information Data Format {(PIDF)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3863,
MONTH=aug,
YEAR=2004,
ABSTRACT="This memo specifies the Common Profile for Presence (CPP) Presence
Information Data Format (PIDF) as a common presence data format for
CPP-compliant Presence protocols, and also defines a new media type
application/pidf+xml to represent the XML MIME entity for PIDF.",
URL="http://www.rfc-editor.org/rfc/rfc3863.txt"
}

@TECHREPORT{rfc3864,
AUTHOR="G. Klyne and M. Nottingham and J. C. Mogul",
TITLE="Registration Procedures for Message Header Fields",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3864,
MONTH=sep,
YEAR=2004,
ABSTRACT="This specification defines registration procedures for the message header
fields used by Internet mail, HTTP, Netnews and other applications.",
URL="http://www.rfc-editor.org/rfc/rfc3864.txt"
}

@TECHREPORT{rfc3865,
AUTHOR="C. Malamud",
TITLE="A No Soliciting Simple Mail Transfer Protocol {(SMTP)} Service Extension",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3865,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document proposes an extension to Soliciting Simple Mail Transfer
Protocol (SMTP) for an electronic mail equivalent to the real-world No
Soliciting sign. In addition to the service extension, a new message header
and extensions to the existing received message header are described.",
URL="http://www.rfc-editor.org/rfc/rfc3865.txt"
}

@TECHREPORT{rfc3866,
AUTHOR="Ed. K. Zeilenga",
TITLE="Language Tags and Ranges in the Lightweight Directory Access Protocol
{(LDAP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3866,
MONTH=jul,
YEAR=2004,
ABSTRACT="It is often desirable to be able to indicate the natural language
associated with values held in a directory and to be able to query the
directory for values which fulfill the user's language needs. This document
details the use of Language Tags and Ranges in the Lightweight Directory
Access Protocol (LDAP).",
URL="http://www.rfc-editor.org/rfc/rfc3866.txt"
}

@TECHREPORT{rfc3867,
AUTHOR="Y. Kawatsura and M. Hiroya and H. Beykirch",
TITLE="Payment Application Programmers Interface {(API)} for v1.0 Internet Open
Trading Protocol {(IOTP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3867,
MONTH=nov,
YEAR=2004,
ABSTRACT="The Internet Open Trading Protocol (IOTP) provides a data exchange format
for trading purposes while integrating existing pure payment protocols
seamlessly. This motivates the multiple layered system architecture which
consists of at least some generic IOTP application core and multiple
specific payment modules.",
URL="http://www.rfc-editor.org/rfc/rfc3867.txt"
}

@TECHREPORT{rfc3868,
AUTHOR="Ed. J. Loughney and G. Sidebottom and L. Coene and G. Verwimp and J. Keller
and B. Bidulock",
TITLE="Signalling Connection Control Part User Adaptation Layer {(SUA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3868,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document defines a protocol for the transport of any Signalling
Connection Control Part-User signalling over IP using the Stream Control
Transmission Protocol. The protocol is designed to be modular and
symmetric, to allow it to work in diverse architectures, such as a
Signalling Gateway to IP Signalling Endpoint architecture as well as a
peer-to-peer IP Signalling Endpoint architecture.",
URL="http://www.rfc-editor.org/rfc/rfc3868.txt"
}

@TECHREPORT{rfc3869,
AUTHOR="Ed. R. Atkinson and Ed. S. Floyd",
TITLE="{IAB} Concerns and Recommendations Regarding Internet Research and
Evolution",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3869,
MONTH=aug,
YEAR=2004,
ABSTRACT="This document discusses IAB concerns that ongoing research is needed to
further the evolution of the Internet infrastructure, and that consistent,
sufficient non-commercial funding is needed to enable such research.",
URL="http://www.rfc-editor.org/rfc/rfc3869.txt"
}

@TECHREPORT{rfc3870,
AUTHOR="A. Swartz",
TITLE="application/rdf+xml Media Type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3870,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document describes a media type (application/rdf+xml) for use with the
Extensible Markup Language (XML) serialization of the Resource Description
Framework (RDF). RDF is a language designed to support the Semantic Web, by
facilitating resource description and data exchange on the Web. RDF
provides common structures that can be used for interoperable data exchange
and follows the World Wide Web Consortium (W3C) design principles of
interoperability, evolution, and decentralization.",
URL="http://www.rfc-editor.org/rfc/rfc3870.txt"
}

@TECHREPORT{rfc3871,
AUTHOR="Ed. G. Jones",
TITLE="Operational Security Requirements for Large Internet Service Provider
{(ISP)} {IP} Network Infrastructure",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3871,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document defines a list of operational security requirements for the
infrastructure of large Internet Service Provider (ISP) IP networks
(routers and switches). A framework is defined for specifying profiles,
which are collections of requirements applicable to certain network
topology contexts (all, core-only, edge-only...). The goal is to provide
network operators a clear, concise way of communicating their security
requirements to vendors.",
URL="http://www.rfc-editor.org/rfc/rfc3871.txt"
}

@TECHREPORT{rfc3873,
AUTHOR="J. Pastor and M. Belinchon",
TITLE="Stream Control Transmission Protocol {(SCTP)} Management Information Base
{(MIB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3873,
MONTH=sep,
YEAR=2004,
ABSTRACT="The Stream Control Transmission Protocol (SCTP) is a reliable transport
protocol operating on top of a connectionless packet network such as IP. It
is designed to transport public switched telephone network (PSTN) signaling
messages over the connectionless packet network, but is capable of broader
applications.",
URL="http://www.rfc-editor.org/rfc/rfc3873.txt"
}

@TECHREPORT{rfc3875,
AUTHOR="D. Robinson and K. Coar",
TITLE="The Common Gateway Interface {(CGI)} Version {1.1}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3875,
MONTH=oct,
YEAR=2004,
ABSTRACT="The Common Gateway Interface (CGI) is a simple interface for running
external programs, software or gateways under an information server in a
platform-independent manner. Currently, the supported information servers
are HTTP servers.",
URL="http://www.rfc-editor.org/rfc/rfc3875.txt"
}

@TECHREPORT{rfc3876,
AUTHOR="D. Chadwick and S. Mullan",
TITLE="Returning Matched Values with the Lightweight Directory Access Protocol
version 3 {(LDAPv3)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3876,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document describes a control for the Lightweight Directory Access
Protocol version 3 that is used to return a subset of attribute values from
an entry. Specifically, only those values that match a values return
filter. Without support for this control, a client must retrieve all of an
attribute's values and search for specific values locally.",
URL="http://www.rfc-editor.org/rfc/rfc3876.txt"
}

@TECHREPORT{rfc3877,
AUTHOR="S. Chisholm and D. Romascanu",
TITLE="Alarm Management Information Base {(MIB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3877,
MONTH=sep,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes management objects used for modelling and storing
alarms.",
URL="http://www.rfc-editor.org/rfc/rfc3877.txt"
}

@TECHREPORT{rfc3878,
AUTHOR="H-k. Lam and A. Huynh and D. Perkins",
TITLE="Alarm Reporting Control Management Information Base {(MIB)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3878,
MONTH=sep,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for controlling the reporting of alarm
conditions.",
URL="http://www.rfc-editor.org/rfc/rfc3878.txt"
}

@TECHREPORT{rfc3879,
AUTHOR="C. Huitema and B. E. Carpenter",
TITLE="Deprecating Site Local Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3879,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document describes the issues surrounding the use of IPv6 site- local
unicast addresses in their original form, and formally deprecates them.
This deprecation does not prevent their continued use until a replacement
has been standardized and implemented.",
URL="http://www.rfc-editor.org/rfc/rfc3879.txt"
}

@TECHREPORT{rfc3880,
AUTHOR="Jonathan Lennox and Xiaotao Wu and Henning Schulzrinne",
TITLE="Call Processing Language {(CPL):} A Language for User Control of Internet
Telephony Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3880,
MONTH=oct,
YEAR=2004,
ABSTRACT="The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is designed to be
implementable on either network servers or user agent servers. It is meant
to be simple, extensible, easily edited by graphical clients, and
independent of operating system or signalling protocol. It is suitable for
running on a server where users may not be allowed to execute arbitrary
programs, as it has no variables, loops, or ability to run external
programs. This document is a product of the IP Telephony (IPTEL) working
group of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at
iptel(at)lists.research.bell-labs.com and/or the authors.",
URL="http://www.ietf.org/rfc/rfc3880.txt"
}

@TECHREPORT{rfc3881,
AUTHOR="G. D. Marshall",
TITLE="Security Audit and Access Accountability Message {XML} Data Definitions for
Healthcare Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3881,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document defines the format of data to be collected and minimum set of
attributes that need to be captured for security auditing in healthcare
application systems. The format is defined as an XML schema, which is
intended as a reference for healthcare standards developers and application
designers. It consolidates several previous documents on security auditing
of healthcare data.",
URL="http://www.rfc-editor.org/rfc/rfc3881.txt"
}

@TECHREPORT{rfc3882,
AUTHOR="D. Turk",
TITLE="Configuring {BGP} to Block {Denial-of-Service} Attacks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3882,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document describes an operational technique that uses BGP communities
to remotely trigger black-holing of a particular destination network to
block denial-of-service attacks. Black-holing can be applied on a selection
of routers rather than all BGP-speaking routers in the network. The
document also describes a sinkhole tunnel technique using BGP communities
and tunnels to pull traffic into a sinkhole router for analysis.",
URL="http://www.rfc-editor.org/rfc/rfc3882.txt"
}

@TECHREPORT{rfc3883,
AUTHOR="S. V. Rao and A. Zinin and A. Roy",
TITLE="Detecting Inactive Neighbors over {OSPF} Demand Circuits {(DC)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3883,
MONTH=oct,
YEAR=2004,
ABSTRACT="OSPF is a link-state intra-domain routing protocol used in IP networks.
OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to
minimize the amount of overhead traffic. A part of the OSPF demand circuit
extensions is the Hello suppression mechanism. This technique allows a
demand circuit to go down when no interesting traffic is going through the
link. However, it also introduces a problem, where it becomes impossible to
detect an OSPF-inactive neighbor over such a link. This memo introduces a
new mechanism called neighbor probing to address the above problem.",
URL="http://www.rfc-editor.org/rfc/rfc3883.txt"
}

@TECHREPORT{rfc3884,
AUTHOR="J. Touch and L. Eggert and Y. Wang",
TITLE="Use of {IPsec} Transport Mode for Dynamic Routing",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3884,
MONTH=sep,
YEAR=2004,
ABSTRACT="IPsec can secure the links of a multihop network to protect communication
between trusted components, e.g., for a secure virtual network (VN),
overlay, or virtual private network (VPN). Virtual links established by
IPsec tunnel mode can conflict with routing and forwarding inside VNs
because IP routing depends on references to interfaces and next-hop IP
addresses. The IPsec tunnel mode specification is ambiguous on this issue,
so even compliant implementations cannot be trusted to avoid conflicts. An
alternative to tunnel mode uses non-IPsec IPIP encapsulation together with
IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a
separate initial step, as the result of a forwarding lookup of the VN
packet. IPsec transport mode processes the resulting (tunneled) IP packet
with an SA determined through a security association database (SAD) match
on the tunnel header. IIPtran supports dynamic routing",
URL="http://www.rfc-editor.org/rfc/rfc3884.txt"
}

@TECHREPORT{rfc3885,
AUTHOR="E. Allman and T. Hansen",
TITLE="{SMTP} Service Extension for Message Tracking",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3885,
MONTH=sep,
YEAR=2004,
ABSTRACT="This memo defines an extension to the SMTP service whereby a client may
mark a message for future tracking.",
URL="http://www.rfc-editor.org/rfc/rfc3885.txt"
}

@TECHREPORT{rfc3886,
AUTHOR="E. Allman",
TITLE="An Extensible Message Format for Message Tracking Responses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3886,
MONTH=sep,
YEAR=2004,
ABSTRACT="Message Tracking is expected to be used to determine the status of
undelivered e-mail upon request. Tracking is used in conjunction with
Delivery Status Notifications (DSN) and Message Disposition Notifications
(MDN); generally, a message tracking request will be issued only when a DSN
or MDN has not been received within a reasonable timeout period.",
URL="http://www.rfc-editor.org/rfc/rfc3886.txt"
}

@TECHREPORT{rfc3887,
AUTHOR="T. Hansen",
TITLE="Message Tracking Query Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3887,
MONTH=sep,
YEAR=2004,
ABSTRACT="Customers buying enterprise message systems often ask: Can I track the
messages? Message tracking is the ability to find out the path that a
particular message has taken through a messaging system and the current
routing status of that message. This document describes the Message
Tracking Query Protocol that is used in conjunction with extensions to the
ESMTP protocol to provide a complete message tracking solution for the
Internet.",
URL="http://www.rfc-editor.org/rfc/rfc3887.txt"
}

@TECHREPORT{rfc3888,
AUTHOR="T. Hansen",
TITLE="Message Tracking Model and Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3888,
MONTH=sep,
YEAR=2004,
ABSTRACT="Customers buying enterprise message systems often ask: Can I track the
messages? Message tracking is the ability to find out the path that a
particular message has taken through a messaging system and the current
routing status of that message. This document provides a model of message
tracking that can be used for understanding the Internet-wide message
infrastructure and to further enhance those capabilities to include message
tracking, as well as requirements for proposed message tracking solutions.",
URL="http://www.rfc-editor.org/rfc/rfc3888.txt"
}

@TECHREPORT{rfc3890,
AUTHOR="M. Westerlund",
TITLE="A Transport Independent Bandwidth Modifier for the Session Description
Protocol {(SDP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3890,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document defines a Session Description Protocol (SDP) Transport
Independent Application Specific Maximum (TIAS) bandwidth modifier that
does not include transport overhead; instead an additional packet rate
attribute is defined. The transport independent bit-rate value together
with the maximum packet rate can then be used to calculate the real
bit-rate over the transport actually used.",
URL="http://www.rfc-editor.org/rfc/rfc3890.txt"
}

@TECHREPORT{rfc3891,
AUTHOR="R. Mahy and B. Biggs and R. Dean",
TITLE="The Session Initiation Protocol {(SIP)} Replaces Header",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3891,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document defines a new header for use with Session Initiation Protocol
(SIP) multi-party applications and call control. The Replaces header is
used to logically replace an existing SIP dialog with a new SIP dialog.
This primitive can be used to enable a variety of features, for example:
Attended Transfer and Call Pickup. Note that the definition of these
example features is non- normative.",
URL="http://www.rfc-editor.org/rfc/rfc3891.txt"
}

@TECHREPORT{rfc3892,
AUTHOR="R. Sparks",
TITLE="The Session Initiation Protocol {(SIP)} {Referred-By} Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3892,
MONTH=sep,
YEAR=2004,
ABSTRACT="The Session Initiation Protocol (SIP) REFER method provides a mechanism
where one party (the referrer) gives a second party (the referee) an
arbitrary URI to reference. If that URI is a SIP URI, the referee will send
a SIP request, often an INVITE, to that URI (the refer target). This
document extends the REFER method, allowing the referrer to provide
information about the REFER request to the refer target using the referee
as an intermediary. This information includes the identity of the referrer
and the URI to which the referrer referred. The mechanism utilizes S/MIME
to help protect this information from a malicious intermediary. This
protection is optional, but a recipient may refuse to accept a request
unless it is present.",
URL="http://www.rfc-editor.org/rfc/rfc3892.txt"
}

@TECHREPORT{rfc3893,
AUTHOR="J. Peterson",
TITLE="Session Initiation Protocol {(SIP)} Authenticated Identity Body {(AIB)}
Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3893,
MONTH=sep,
YEAR=2004,
ABSTRACT="RFC 3261 introduces the concept of adding an S/MIME body to a Session
Initiation Protocol (SIP) request or response in order to provide reference
integrity over its headers. This document provides a more specific
mechanism to derive integrity and authentication properties from an
'authenticated identity body', a digitally-signed SIP message, or message
fragment. A standard format for such bodies (known as Authenticated
Identity Bodies, or AIBs) is given in this document. Some considerations
for the processing of AIBs by recipients of SIP messages with such bodies
are also given.",
URL="http://www.rfc-editor.org/rfc/rfc3893.txt"
}

@TECHREPORT{rfc3894,
AUTHOR="J. Degener",
TITLE="Sieve Extension: Copying Without Side Effects",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3894,
MONTH=oct,
YEAR=2004,
ABSTRACT="The Sieve scripting language allows users to control handling and disposal
of their incoming e-mail. By default, an e-mail message that is processed
by a Sieve script is saved in the owner's inbox. Actions such as fileinto
and redirect cancel this default behavior.",
URL="http://www.rfc-editor.org/rfc/rfc3894.txt"
}

@TECHREPORT{rfc3895,
AUTHOR="Ed. O. Nicklass",
TITLE="Definitions of Managed Objects for the {DS1,} {E1,} {DS2,} and {E2}
Interface Types",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3895,
MONTH=sep,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes objects used for managing DS1, E1, DS2 and E2
interfaces. This document is a companion to the documents that define
Managed Objects for the DS0, DS3/E3 and Synchronous Optical
Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This
document obsoletes RFC 2495.",
URL="http://www.rfc-editor.org/rfc/rfc3895.txt"
}

@TECHREPORT{rfc3896,
AUTHOR="Ed. O. Nicklass",
TITLE="Definitions of Managed Objects for the {DS3/E3} Interface Type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3896,
MONTH=sep,
YEAR=2004,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes objects used for managing DS3 and E3 interfaces.
This document is a companion to the documents that define Managed Objects
for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous
Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC
2496.",
URL="http://www.rfc-editor.org/rfc/rfc3896.txt"
}

@TECHREPORT{rfc3897,
AUTHOR="A. Barbir",
TITLE="Open Pluggable Edge Services {(OPES)} Entities and End Points Communication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3897,
MONTH=sep,
YEAR=2004,
ABSTRACT="This memo documents tracing and non-blocking (bypass) requirements for Open
Pluggable Edge Services (OPES).",
URL="http://www.rfc-editor.org/rfc/rfc3897.txt"
}

@TECHREPORT{rfc3898,
AUTHOR="V. Kalusivalingam",
TITLE="Network Information Service {(NIS)} Configuration Options for Dynamic Host
Configuration Protocol for {IPv6} {(DHCPv6)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3898,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document describes four options for Network Information Service (NIS)
related configuration information in Dynamic Host Configuration Protocol
for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+
Client Domain name.",
URL="http://www.rfc-editor.org/rfc/rfc3898.txt"
}

@TECHREPORT{rfc3901,
AUTHOR="A. Durand and J. Ihren",
TITLE="{DNS} {IPv6} Transport Operational Guidelines",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3901,
MONTH=sep,
YEAR=2004,
ABSTRACT="This memo provides guidelines and Best Current Practice for operating DNS
in a world where queries and responses are carried in a mixed environment
of IPv4 and IPv6 networks.",
URL="http://www.rfc-editor.org/rfc/rfc3901.txt"
}

@TECHREPORT{rfc3902,
AUTHOR="M. Baker and M. Nottingham",
TITLE="The application/soap+xml media type",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3902,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document defines the application/soap+xml media type which can be used
to describe SOAP 1.2 messages serialized as XML 1.0.",
URL="http://www.rfc-editor.org/rfc/rfc3902.txt"
}

@TECHREPORT{rfc3903,
AUTHOR="Aki Niemi",
TITLE="Session Initiation Protocol {({SIP})} Extension for Event State Publication",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3903,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document describes an extension to the Session Initiation
Protocol (SIP) for publishing event state used within the SIP Events
framework.  The first application of this extension is for the publication
of presence information.

The mechanism described in this document can be extended to support
publication of any event state for which there exists an appropriate
event package.  It is not intended to be a general-purpose mechanism for
transport of arbitrary data, as there are better-suited mechanisms for this
purpose.",
URL="http://www.rfc-editor.org/rfc/rfc3903.txt"
}

@TECHREPORT{rfc3904,
AUTHOR="C. Huitema and R. Austein and S. Satapati and R. {van der Pol}",
TITLE="Evaluation of {IPv6} Transition Mechanisms for Unmanaged Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3904,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document analyzes issues involved in the transition of unmanaged
networks from IPv4 to IPv6. Unmanaged networks typically correspond to home
networks or small office networks. A companion paper analyzes out the
requirements for mechanisms needed in various transition scenarios of these
networks to IPv6. Starting from this analysis, we evaluate the suitability
of mechanisms that have already been specified, proposed, or deployed.",
URL="http://www.rfc-editor.org/rfc/rfc3904.txt"
}

@TECHREPORT{rfc3905,
AUTHOR="Ed. V. See",
TITLE="A Template for {IETF} Patent Disclosures and Licensing Declarations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3905,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document describes a proposal for one form of a template for IETF
patent disclosures and licensing declarations. The optional use of this
template is meant to simplify the process of such disclosures and licensing
declarations and to assist disclosers in providing the necessary
information to meet the obligations documented in RFC 3668.",
URL="http://www.rfc-editor.org/rfc/rfc3905.txt"
}

@TECHREPORT{rfc3906,
AUTHOR="N. Shen and H. Smit",
TITLE="Calculating Interior Gateway Protocol {(IGP)} Routes Over Traffic
Engineering Tunnels",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3906,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document describes how conventional hop-by-hop link-state routing
protocols interact with new Traffic Engineering capabilities to create
Interior Gateway Protocol (IGP) shortcuts. In particular, this document
describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted
so that link-state IGPs will calculate IP routes to forward traffic over
tunnels that are set up by Traffic Engineering.",
URL="http://www.rfc-editor.org/rfc/rfc3906.txt"
}

@TECHREPORT{rfc3909,
AUTHOR="K. Zeilenga",
TITLE="Lightweight Directory Access Protocol {(LDAP)} Cancel Operation",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3909,
MONTH=oct,
YEAR=2004,
ABSTRACT="This specification describes a Lightweight Directory Access Protocol (LDAP)
extended operation to cancel (or abandon) an outstanding operation. Unlike
the LDAP Abandon operation, but like the X.511 Directory Access Protocol
(DAP) Abandon operation, this operation has a response which provides an
indication of its outcome.",
URL="http://www.rfc-editor.org/rfc/rfc3909.txt"
}

@TECHREPORT{rfc3911,
AUTHOR="R. Mahy and D. Petrie",
TITLE="The Session Initiation Protocol {(SIP)} Join Header",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3911,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document defines a new header for use with SIP multi-party
applications and call control. The Join header is used to logically join an
existing SIP dialog with a new SIP dialog. This primitive can be used to
enable a variety of features, for example: Barge-In,
answering-machine-style Message Screening and Call Center Monitoring. Note
that definition of these example features is non- normative.",
URL="http://www.rfc-editor.org/rfc/rfc3911.txt"
}

@TECHREPORT{rfc3912,
AUTHOR="L. Daigle",
TITLE="{WHOIS} Protocol Specification",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3912,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document updates the specification of the WHOIS protocol, thereby
obsoleting RFC 954. The update is intended to remove the material from RFC
954 that does not have to do with the on-the-wire protocol, and is no
longer applicable in today's Internet. This document does not attempt to
change or update the protocol per se, or document other uses of the
protocol that have come into existence since the publication of RFC 954.",
URL="http://www.rfc-editor.org/rfc/rfc3912.txt"
}

@TECHREPORT{rfc3914,
AUTHOR="A. Barbir and Alex Rousskov",
TITLE="Open Pluggable Edge Services {(OPES)} Treatment of {IAB} Considerations",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3914,
MONTH=oct,
YEAR=2004,
ABSTRACT="IETF Internet Architecture Board (IAB) expressed nine architecture- level
considerations for the Open Pluggable Edge Services (OPES) framework. This
document describes how OPES addresses those considerations.",
URL="http://www.rfc-editor.org/rfc/rfc3914.txt"
}

@TECHREPORT{rfc3915,
AUTHOR="S. Hollenbeck",
TITLE="Domain Registry Grace Period Mapping for the Extensible Provisioning
Protocol {(EPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3915,
MONTH=sep,
YEAR=2004,
ABSTRACT="This document describes an Extensible Provisioning Protocol (EPP) extension
mapping for the management of Domain Name System (DNS) domain names subject
to grace period policies defined by the Internet Corporation for Assigned
Names and Numbers (ICANN). Grace period policies exist to allow protocol
actions to be reversed or otherwise revoked during a short period of time
after the protocol action has been performed. Specified in XML, this
mapping extends the EPP domain name mapping to provide additional features
required for grace period processing.",
URL="http://www.rfc-editor.org/rfc/rfc3915.txt"
}

@TECHREPORT{rfc3917,
AUTHOR="Juergen Quittek and Tanja Zseby and B. Claise and S. Zander",
TITLE="Requirements for {IP} Flow Information Export {(IPFIX)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3917,
MONTH=oct,
YEAR=2004,
ABSTRACT="This memo defines requirements for the export of measured IP flow
information out of routers, traffic measurement probes, and middleboxes.",
URL="http://www.rfc-editor.org/rfc/rfc3917.txt"
}

@TECHREPORT{rfc3919,
AUTHOR="E. Stephan and J. Palet",
TITLE="Remote Network Monitoring {(RMON)} Protocol Identifiers for {IPv6} and
Multi Protocol Label Switching {(MPLS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3919,
MONTH=oct,
YEAR=2004,
ABSTRACT="This memo defines additional (to those in RFC 2896) protocol identifier
examples for IP version 6 and MPLS protocols. These can be used to produce
valid protocolDirTable INDEX encodings, as defined by the Remote Network
Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the
RMON Protocol Identifier Reference [RFC2895].",
URL="http://www.rfc-editor.org/rfc/rfc3919.txt"
}

@TECHREPORT{rfc3920,
AUTHOR="Peter Saint-Andre",
TITLE="Extensible Messaging and Presence Protocol {(XMPP):} Core",
TYPE="RFC",
INSTITUTION="IETF",
NUMBER=3920,
MONTH=oct,
YEAR=2004,
KEYWORDS="presence; IM",
ABSTRACT="This memo defines the core features of the Extensible Messaging and
Presence Protocol (XMPP), a protocol for streaming Extensible Markup
Language (XML) elements in order to exchange structured information
in close to real time between any two network endpoints.  While XMPP
provides a generalized, extensible framework for exchanging XML data,
it is used mainly for the purpose of building instant messaging and
presence applications that meet the requirements of RFC 2779.",
URL="http://www.rfc-editor.org/rfc/rfc3920.txt"
}

@TECHREPORT{rfc3922,
AUTHOR="P. Saint-Andre",
TITLE="Mapping the Extensible Messaging and Presence Protocol {(XMPP)} to Common
Presence and Instant Messaging {(CPIM)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3922,
MONTH=oct,
YEAR=2004,
ABSTRACT="This memo describes a mapping between the Extensible Messaging and Presence
Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM)
specifications.",
URL="http://www.rfc-editor.org/rfc/rfc3922.txt"
}

@TECHREPORT{rfc3923,
AUTHOR="P. Saint-Andre",
TITLE="{End-to-End} Signing and Object Encryption for the Extensible Messaging and
Presence Protocol {(XMPP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3923,
MONTH=oct,
YEAR=2004,
ABSTRACT="This memo defines methods of end-to-end signing and object encryption for
the Extensible Messaging and Presence Protocol (XMPP).",
URL="http://www.rfc-editor.org/rfc/rfc3923.txt"
}

@TECHREPORT{rfc3924,
AUTHOR="F. Baker and B. Foster and C. Sharp",
TITLE="Cisco Architecture for Lawful Intercept in {IP} Networks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3924,
MONTH=oct,
YEAR=2004,
ABSTRACT="For the purposes of this document, lawful intercept is the lawfully
authorized interception and monitoring of communications. Service providers
are being asked to meet legal and regulatory requirements for the
interception of voice as well as data communications in IP networks in a
variety of countries worldwide. Although requirements vary from country to
country, some requirements remain common even though details such as
delivery formats may differ. This document describes Cisco's Architecture
for supporting lawful intercept in IP networks. It provides a general
solution that has a minimum set of common interfaces. This document does
not attempt to address any of the specific legal requirements or
obligations that may exist in a particular country.",
URL="http://www.rfc-editor.org/rfc/rfc3924.txt"
}

@TECHREPORT{rfc3925,
AUTHOR="J. Littlefield",
TITLE="{Vendor-Identifying} Vendor Options for Dynamic Host Configuration Protocol
version 4 {(DHCPv4)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3925,
MONTH=oct,
YEAR=2004,
ABSTRACT="The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and
Vendor-Specific Information can be limiting or ambiguous when a DHCP client
represents multiple vendors. This document defines two new options, modeled
on the IPv6 options for vendor class and vendor-specific information, that
contain Enterprise Numbers to remove ambiguity.",
URL="http://www.rfc-editor.org/rfc/rfc3925.txt"
}

@TECHREPORT{rfc3926,
AUTHOR="T. Paila and M. Luby and R. Lehtonen and Vincent Roca and Robert Walsh",
TITLE="{FLUTE} - File Delivery over Unidirectional Transport",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3926,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document defines FLUTE, a protocol for the unidirectional delivery of
files over the Internet, which is particularly suited to multicast
networks. The specification builds on Asynchronous Layered Coding, the base
protocol designed for massively scalable multicast distribution.",
URL="http://www.rfc-editor.org/rfc/rfc3926.txt"
}

@TECHREPORT{rfc3928,
AUTHOR="Ed. R. Megginson and M. Smith and O. Natkovich and J. Parham",
TITLE="Lightweight Directory Access Protocol {(LDAP)} Client Update Protocol
{(LCUP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3928,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document defines the Lightweight Directory Access Protocol (LDAP)
Client Update Protocol (LCUP). The protocol is intended to allow an LDAP
client to synchronize with the content of a directory information tree
(DIT) stored by an LDAP server and to be notified about the changes to that
content.",
URL="http://www.rfc-editor.org/rfc/rfc3928.txt"
}

@TECHREPORT{rfc3929,
AUTHOR="T. Hardie",
TITLE="Alternative Decision Making Processes for {Consensus-Blocked} Decisions in
the {IETF}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3929,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document proposes an experimental set of alternative decision- making
processes for use in IETF working groups. There are a small number of cases
in IETF working groups in which the group has come to consensus that a
particular decision must be made but cannot agree on the decision itself.
This document describes alternative mechanisms for reaching a decision in
those cases. This is not meant to provide an exhaustive list, but to
provide a known set of tools that can be used when needed.",
URL="http://www.rfc-editor.org/rfc/rfc3929.txt"
}

@TECHREPORT{rfc3930,
AUTHOR="D. Eastlake 3rd",
TITLE="The Protocol versus Document Points of View in Computer Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3930,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document contrasts two points of view: the document point of view,
where digital objects of interest are like pieces of paper written and
viewed by people, and the protocol point of view where objects of interest
are composite dynamic network messages. Although each point of view has a
place, adherence to a document point of view can be damaging to protocol
design. By understanding both points of view, conflicts between them may be
clarified and reduced.",
URL="http://www.rfc-editor.org/rfc/rfc3930.txt"
}

@TECHREPORT{rfc3932,
AUTHOR="H. Alvestrand",
TITLE="The {IESG} and {RFC} Editor Documents: Procedures",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3932,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document describes the IESG's procedures for handling documents
submitted for RFC publication via the RFC Editor, subsequent to the changes
proposed by the IESG at the Seoul IETF, March 2004.",
URL="http://www.rfc-editor.org/rfc/rfc3932.txt"
}

@TECHREPORT{rfc3934,
AUTHOR="M. Wasserman",
TITLE="Updates to {RFC} 2418 Regarding the Management of {IETF} Mailing Lists",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3934,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document is an update to RFC 2418 that gives WG chairs explicit
responsibility for managing WG mailing lists. In particular, it gives WG
chairs the authority to temporarily suspend the mailing list posting
privileges of disruptive individuals.",
URL="http://www.rfc-editor.org/rfc/rfc3934.txt"
}

@TECHREPORT{rfc3936,
AUTHOR="K. Kompella and J. Lang",
TITLE="Procedures for Modifying the Resource {reSerVation} Protocol {(RSVP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3936,
MONTH=oct,
YEAR=2004,
ABSTRACT="This memo specifies procedures for modifying the Resource reSerVation
Protocol (RSVP). This memo also lays out new assignment guidelines for
number spaces for RSVP messages, object classes, class-types, and
sub-objects.",
URL="http://www.rfc-editor.org/rfc/rfc3936.txt"
}

@TECHREPORT{rfc3937,
AUTHOR="M. Steidl",
TITLE="A Uniform Resource Name {(URN)} Namespace for the International Press
Telecommunications Council {(IPTC)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3937,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document describes a URN (Uniform Resource Name) namespace for
identifying persistent resources published by the International Press
Telecommunications Council (IPTC). These resources include XML Data Type
Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets,
other XML based document and documents of other data formats like PDF
documents, Microsoft Office documents and others.",
URL="http://www.rfc-editor.org/rfc/rfc3937.txt"
}

@TECHREPORT{rfc3938,
AUTHOR="T. Hansen",
TITLE="{Video-Message} {Message-Context}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3938,
MONTH=oct,
YEAR=2004,
ABSTRACT="The Message-Context header defined in RFC 3458 describes the context of a
message (for example: fax-message or voice-message). This specification
extends the Message-Context header with one additional context value:
video-message.",
URL="http://www.rfc-editor.org/rfc/rfc3938.txt"
}

@TECHREPORT{rfc3939,
AUTHOR="G. Parsons and J. Maruszak",
TITLE="Calling Line Identification for Voice Mail Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3939,
MONTH=dec,
YEAR=2004,
ABSTRACT="This document describes a method for identifying the originating calling
party in the headers of a stored voice mail message. Two new header fields
are defined for this purpose: Caller\_ID and Called\_Name. Caller\_id is
used to store sufficient information for the recipient to callback, or
reply to, the sender of the message. Caller-name provides the name of the
person sending the message.",
URL="http://www.rfc-editor.org/rfc/rfc3939.txt"
}

@TECHREPORT{rfc3940,
AUTHOR="B. Adamson and C. Bormann and M. Handley and J. P. Macker",
TITLE="Negative-acknowledgment {(NACK)-Oriented} Reliable Multicast {(NORM)}
Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3940,
MONTH=nov,
YEAR=2004,
ABSTRACT="This document describes the messages and procedures of the Negative-
acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This
protocol is designed to provide end-to-end reliable transport of bulk data
objects or streams over generic IP multicast routing and forwarding
services. NORM uses a selective, negative acknowledgment mechanism for
transport reliability and offers additional protocol mechanisms to allow
for operation with minimal a priori coordination among senders and
receivers. A congestion control scheme is specified to allow the NORM
protocol to fairly share available network bandwidth with other transport
protocols such as Transmission Control Protocol (TCP). It is capable of
operating with both reciprocal multicast routing among senders and
receivers and with asymmetric connectivity (possibly a unicast return path)
between the senders and receivers. The protocol offers a number of features
to allow different types of applications or possibly other higher level
transport protocols to utilize its service in different ways. The protocol
leverages the use of FEC-based repair and other IETF reliable multicast
transport (RMT) building blocks in its design.",
URL="http://www.rfc-editor.org/rfc/rfc3940.txt"
}

@TECHREPORT{rfc3941,
AUTHOR="B. Adamson and C. Bormann and M. Handley and J. P. Macker",
TITLE="{Negative-Acknowledgment} {(NACK)-Oriented} Reliable Multicast {(NORM)}
Building Blocks",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3941,
MONTH=nov,
YEAR=2004,
ABSTRACT="This document discusses the creation of negative-acknowledgment
(NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM
goals and assumptions are presented. Technical challenges for NACK-oriented
(and in some cases general) reliable multicast protocol operation are
identified. These goals and challenges are resolved into a set of
functional building blocks that address different aspects of NORM protocol
operation. It is anticipated that these building blocks will be useful in
generating different instantiations of reliable multicast protocols.",
URL="http://www.rfc-editor.org/rfc/rfc3941.txt"
}

@TECHREPORT{rfc3942,
AUTHOR="B. Volz",
TITLE="Reclassifying Dynamic Host Configuration Protocol version 4 {(DHCPv4)}
Options",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3942,
PAGES=7,
DAYS=15,
MONTH=nov,
YEAR=2004,
ABSTRACT="This document updates RFC 2132 to reclassify Dynamic Host
Configuration Protocol version 4 (DHCPv4) option codes 128 to 223
(decimal) as publicly defined options to be managed by IANA in
accordance with RFC 2939.  This document directs IANA to make these
option codes available for assignment as publicly defined DHCP options
for future options.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.",
URL="http://www.rfc-editor.org/rfc/rfc3942.txt"
}

@TECHREPORT{rfc3943,
AUTHOR="R. Friend",
TITLE="Transport Layer Security {(TLS)} Protocol Compression Using
{Lempel-Ziv-Stac} {(LZS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3943,
PAGES=13,
DAYS=15,
MONTH=nov,
YEAR=2004,
ABSTRACT="The Transport Layer Security (TLS) protocol (RFC 2246) includes
features to negotiate selection of a lossless data compression method
as part of the TLS Handshake Protocol and then to apply the algorithm
associated with the selected method as part of the TLS Record
Protocol.  TLS defines one standard compression method, which
specifies that data exchanged via the record protocol will not be
compressed.  This document describes an additional compression method
associated with the Lempel-Ziv-Stac (LZS) lossless data compression
algorithm for use with TLS.  This document also defines the
application of the LZS algorithm to the TLS Record Protocol.",
URL="http://www.rfc-editor.org/rfc/rfc3943.txt"
}

@TECHREPORT{rfc3944,
AUTHOR="T. Johnson and U. {of North Carolina} and S. Okubo and Sergio Campos",
TITLE="{H.350} Directory Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3944,
MONTH=dec,
YEAR=2004,
ABSTRACT="The International Telecommunications Union Standardization Sector (ITU-T)
has created the H.350 series of Recommendations that specify directory
services architectures in support of multimedia conferencing protocols. The
goal of the architecture is to 'directory enable' multimedia conferencing
so that these services can leverage existing identity management and
enterprise directories. A particular goal is to enable an enterprise or
service provider to maintain a canonical source of users and their
multimedia conferencing systems, so that multiple call servers from
multiple vendors, supporting multiple protocols, can all access the same
data store.",
URL="http://www.rfc-editor.org/rfc/rfc3944.txt"
}

@TECHREPORT{rfc3945,
AUTHOR="Ed. E. Mannie",
TITLE="Generalized {Multi-Protocol} Label Switching {(GMPLS)} Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3945,
MONTH=oct,
YEAR=2004,
ABSTRACT="Future data and transmission networks will consist of elements such as
routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems,
Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical
cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label
Switching (GMPLS) to dynamically provision resources and to provide network
survivability using protection and restoration techniques.",
URL="http://www.rfc-editor.org/rfc/rfc3945.txt"
}

@TECHREPORT{rfc3946,
AUTHOR="E. Mannie and D. Papadimitriou",
TITLE="Generalized {Multi-Protocol} Label Switching {(GMPLS)} Extensions for
Synchronous Optical Network {(SONET)} and Synchronous Digital Hierarchy
{(SDH)} Control",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3946,
MONTH=oct,
YEAR=2004,
ABSTRACT="This document is a companion to the Generalized Multi-Protocol Label
Switching (GMPLS) signaling. It defines the Synchronous Optical Network
(SONET)/Synchronous Digital Hierarchy (SDH) technology specific information
needed when using GMPLS signaling.",
URL="http://www.rfc-editor.org/rfc/rfc3946.txt"
}

@TECHREPORT{rfc3951,
AUTHOR="S. C. Andersen and A. Duric and H. Astrom and R. Hagen and W. B. Kleijn and
J. Linden",
TITLE="Internet Low Bit Rate Codec {(iLBC)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3951,
MONTH=dec,
YEAR=2004,
ABSTRACT="This document specifies a speech codec suitable for robust voice
communication over IP. The codec is developed by Global IP Sound (GIPS). It
is designed for narrow band speech and results in a payload bit rate of
13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec
enables graceful speech quality degradation in the case of lost frames,
which occurs in connection with lost or delayed IP packets.",
URL="http://www.rfc-editor.org/rfc/rfc3951.txt"
}

@TECHREPORT{rfc3952,
AUTHOR="A. Duric and S. C. Andersen",
TITLE="Real-time Transport Protocol {(RTP)} Payload Format for internet Low Bit
Rate Codec {(iLBC)} Speech",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3952,
MONTH=dec,
YEAR=2004,
ABSTRACT="This document describes the Real-time Transport Protocol (RTP) payload
format for the internet Low Bit Rate Codec (iLBC) Speech developed by
Global IP Sound (GIPS). Also, within the document there are included
necessary details for the use of iLBC with MIME and Session Description
Protocol (SDP).",
URL="http://www.rfc-editor.org/rfc/rfc3952.txt"
}

@TECHREPORT{rfc3960,
AUTHOR="Gonzalo  Camarillo and Henning Schulzrinne",
TITLE="Early Media and Ringing Tone Generation in the Session Initiation Protocol
{(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3960,
MONTH=dec,
YEAR=2004,
ABSTRACT="This document describes how to manage early media in the Session Initiation
Protocol (SIP) using two      s: the gateway       and the application
server      . It also describes the inputs one needs to consider in
defining local policies for ringing tone generation. This memo provides
information for the Internet community.",
URL="http://www.rfc-editor.org/rfc/rfc3960.txt"
}

@TECHREPORT{rfc3965,
AUTHOR="K. Toyoda and H. Ohno and J. Murai and D. Wing",
TITLE="A Simple Mode of Facsimile Using Internet Mail",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3965,
MONTH=dec,
YEAR=2004,
ABSTRACT="This specification provides for simple mode carriage of facsimile data
using Internet mail. Extensions to this document will follow. The current
specification employs standard protocols and file formats such as TCP/IP,
Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and
Tagged Image File Format (TIFF) for Facsimile. 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.",
URL="http://www.rfc-editor.org/rfc/rfc3965.txt"
}

@TECHREPORT{rfc3966,
AUTHOR="Henning Schulzrinne",
TITLE="The tel {URI} for Telephone Numbers",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3966,
MONTH=dec,
YEAR=2004,
ABSTRACT={This document specifies the URI (Uniform Resource Identifier) scheme
{"}tel{"}. The {"}tel{"} URI describes resources identified by telephone
numbers. This document obsoletes RFC 2806.},
URL="http://www.rfc-editor.org/rfc/rfc3966.txt"
}

@TECHREPORT{rfc3967,
AUTHOR="R. Bush and T. Narten",
TITLE="Clarifying when Standards Track Documents may Refer Normatively to
Documents at a Lower Level",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3967,
MONTH=dec,
YEAR=2004,
ABSTRACT="IETF procedures generally require that a standards track RFC may not have a
normative reference to another standards track document at a lower maturity
level or to a non standards track specification (other than specifications
from other standards bodies). For example, a standards track document may
not have a normative reference to an informational RFC. Exceptions to this
rule are sometimes needed as the IETF uses informational RFCs to describe
non-IETF standards or IETF-specific modes of use of such standards. This
document clarifies and updates the procedure used in these circumstances.",
URL="http://www.rfc-editor.org/rfc/rfc3967.txt"
}

@TECHREPORT{rfc3968,
AUTHOR="G. Camarillo",
TITLE="The Internet Assigned Number Authority {(IANA)} Header Field Parameter
Registry for the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3968,
MONTH=dec,
YEAR=2004,
ABSTRACT="This document creates an Internet Assigned Number Authority (IANA) registry
for the Session Initiation Protocol (SIP) header field parameters and
parameter values. It also lists the already existing parameters and
parameter values to be used as the initial entries for this registry.",
URL="http://www.rfc-editor.org/rfc/rfc3968.txt"
}

@TECHREPORT{rfc3969,
AUTHOR="G. Camarillo",
TITLE="The Internet Assigned Number Authority {(IANA)} Uniform Resource Identifier
{(URI)} Parameter Registry for the Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3969,
MONTH=dec,
YEAR=2004,
ABSTRACT="This document creates an Internet Assigned Number Authority (IANA) registry
for the Session Initiation Protocol (SIP) and SIPS Uniform Resource
Identifier (URI) parameters, and their values. It also lists the already
existing parameters to be used as initial values for that registry.",
URL="http://www.rfc-editor.org/rfc/rfc3969.txt"
}

@TECHREPORT{rfc3927,
AUTHOR="S. Cheshire and B. Aboba and E. Guttman",
TITLE="Dynamic Configuration of {IPv4} {Link-Local} Addresses",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3927,
MONTH=mar,
YEAR=2005,
ABSTRACT="To participate in wide-area IP networking, a host needs to be configured
with IP addresses for its interfaces, either manually by the user or
automatically from a source on the network such as a Dynamic Host
Configuration Protocol (DHCP) server. Unfortunately, such address
configuration information may not always be available. It is therefore
beneficial for a host to be able to depend on a useful subset of IP
networking functions even when no address configuration is available. This
document describes how a host may automatically configure an interface with
an IPv4 address within the 169.254/16 prefix that is valid for
communication with other devices connected to the same physical (or
logical) link.",
URL="http://www.rfc-editor.org/rfc/rfc3927.txt"
}

@TECHREPORT{rfc3931,
AUTHOR="Ed. J. Lau and Ed. M. Townsley and Ed. I. Goyret",
TITLE="Layer Two Tunneling Protocol - Version 3 {(L2TPv3)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3931,
MONTH=mar,
YEAR=2005,
ABSTRACT="This document describes version 3 of the Layer Two Tunneling Protocol
(L2TPv3). L2TPv3 defines the base control protocol and encapsulation for
tunneling multiple Layer 2 connections between two IP nodes. Additional
documents detail the specifics for each data link type being emulated.",
URL="http://www.rfc-editor.org/rfc/rfc3931.txt"
}

@TECHREPORT{rfc3947,
AUTHOR="T. Kivinen and B. Swander and A. Huttunen and V. Volpe",
TITLE="Negotiation of {NAT-Traversal} in the {IKE}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3947,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document describes how to detect one or more network address
translation devices (NATs) between IPsec hosts, and how to negotiate the
use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key
Exchange (IKE).",
URL="http://www.rfc-editor.org/rfc/rfc3947.txt"
}

@TECHREPORT{rfc3948,
AUTHOR="A. Huttunen and B. Swander and V. Volpe and L. DiBurro and M. Stenberg",
TITLE="{UDP} Encapsulation of {IPsec} {ESP} Packets",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3948,
MONTH=jan,
YEAR=2005,
ABSTRACT="This protocol specification defines methods to encapsulate and decapsulate
IP Encapsulating Security Payload (ESP) packets inside UDP packets for
traversing Network Address Translators. ESP encapsulation, as defined in
this document, can be used in both IPv4 and IPv6 scenarios. Whenever
negotiated, encapsulation is used with Internet Key Exchange (IKE).",
URL="http://www.rfc-editor.org/rfc/rfc3948.txt"
}

@TECHREPORT{rfc3949,
AUTHOR="R. Buckley and D. Venable and L. McIntyre and G. Parsons and J. Rafferty",
TITLE="File Format for Internet Fax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3949,
MONTH=feb,
YEAR=2005,
ABSTRACT="This document is a revised version of RFC 2301. The revisions, summarized
in the list attached as Annex B, are based on discussions and suggestions
for improvements that have been made since RFC 2301 was issued in March
1998, and on the results of independent implementations and
interoperability testing.",
URL="http://www.rfc-editor.org/rfc/rfc3949.txt"
}

@TECHREPORT{rfc3950,
AUTHOR="L. McIntyre and G. Parsons and J. Rafferty",
TITLE="Tag Image File Format Fax eXtended {(TIFF-FX)} - image/tiff-fx {MIME}
Sub-type Registration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3950,
MONTH=feb,
YEAR=2005,
ABSTRACT="This document describes the registration of the MIME sub-type
image/tiff-fx. The encodings are defined by File Format for Internet Fax
and its extensions.",
URL="http://www.rfc-editor.org/rfc/rfc3950.txt"
}

@TECHREPORT{rfc3953,
AUTHOR="J. Peterson",
TITLE="Telephone Number Mapping {(ENUM)} Service Registration for Presence
Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3953,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document registers a Telephone Number Mapping (ENUM) service for
presence. Specifically, this document focuses on provisioning pres URIs in
ENUM.",
URL="http://www.rfc-editor.org/rfc/rfc3953.txt"
}

@TECHREPORT{rfc3957,
AUTHOR="C. E. Perkins and P. Calhoun",
TITLE="Authentication, Authorization, and Accounting {(AAA)} Registration Keys for
Mobile {IPv4}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3957,
MONTH=mar,
YEAR=2005,
ABSTRACT="Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS
and DIAMETER, are in use within the Internet today to provide
authentication and authorization services for dial-up computers. Mobile IP
for IPv4 requires strong authentication between the mobile node and its
home agent. When the mobile node shares an AAA Security Association with
its home AAA server, however, it is possible to use that AAA Security
Association to create derived Mobility Security Associations between the
mobile node and its home agent, and again between the mobile node and the
foreign agent currently offering connectivity to the mobile node. This
document specifies extensions to Mobile IP registration messages that can
be used to create Mobility Security Associations between the mobile node
and its home agent, and/or between the mobile node and a foreign agent.",
URL="http://www.rfc-editor.org/rfc/rfc3957.txt"
}

@TECHREPORT{rfc3958,
AUTHOR="L. Daigle and A. Newton",
TITLE="{Domain-Based} Application Service Location Using {SRV} {RRs} and the
Dynamic Delegation Discovery Service {(DDDS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3958,
MONTH=jan,
YEAR=2005,
ABSTRACT="This memo defines a generalized mechanism for application service naming
that allows service location without relying on rigid domain naming
conventions (so-called name hacks). The proposal defines a Dynamic
Delegation Discovery System (DDDS) Application to map domain name,
application service name, and application protocol dynamically to target
server and port.",
URL="http://www.rfc-editor.org/rfc/rfc3958.txt"
}

@TECHREPORT{rfc3961,
AUTHOR="K. Raeburn",
TITLE="Encryption and Checksum Specifications for Kerberos 5",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3961,
MONTH=feb,
YEAR=2005,
ABSTRACT="This document describes a framework for defining encryption and checksum
mechanisms for use with the Kerberos protocol, defining an abstraction
layer between the Kerberos protocol and related protocols, and the actual
mechanisms themselves. The document also defines several mechanisms. Some
are taken from RFC 1510, modified in form to fit this new framework and
occasionally modified in content when the old specification was incorrect.
New mechanisms are presented here as well. This document does NOT indicate
which mechanisms may be considered required to implement.",
URL="http://www.rfc-editor.org/rfc/rfc3961.txt"
}

@TECHREPORT{rfc3962,
AUTHOR="K. Raeburn",
TITLE="Advanced Encryption Standard {(AES)} Encryption for Kerberos 5",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3962,
MONTH=feb,
YEAR=2005,
ABSTRACT="The United States National Institute of Standards and Technology (NIST) has
chosen a new Advanced Encryption Standard (AES), which is significantly
faster and (it is believed) more secure than the old Data Encryption
Standard (DES) algorithm. This document is a specification for the addition
of this algorithm to the Kerberos cryptosystem suite.",
URL="http://www.rfc-editor.org/rfc/rfc3962.txt"
}

@TECHREPORT{rfc3963,
AUTHOR="V. Devarapalli and R. Wakikawa and A. Petrescu and P. Thubert",
TITLE="Network Mobility {(NEMO)} Basic Support Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3963,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document describes the Network Mobility (NEMO) Basic Support protocol
that enables Mobile Networks to attach to different points in the Internet.
The protocol is an extension of Mobile IPv6 and allows session continuity
for every node in the Mobile Network as the network moves. It also allows
every node in the Mobile Network to be reachable while moving around. The
Mobile Router, which connects the network to the Internet, runs the NEMO
Basic Support protocol with its Home Agent. The protocol is designed so
that network mobility is transparent to the nodes inside the Mobile
Network.",
URL="http://www.rfc-editor.org/rfc/rfc3963.txt"
}

@TECHREPORT{rfc3970,
AUTHOR="K. Kompella",
TITLE="A Traffic Engineering {(TE)} {MIB}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3970,
MONTH=jan,
YEAR=2005,
ABSTRACT="This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes managed objects for Traffic Engineered (TE)
Tunnels; for example, Multi-Protocol Label Switched Paths.",
URL="http://www.rfc-editor.org/rfc/rfc3970.txt"
}

@TECHREPORT{rfc3971,
AUTHOR="Ed. J. Arkko and J. Kempf and B. Zill and P. Nikander",
TITLE="{SEcure} Neighbor Discovery {(SEND)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3971,
MONTH=mar,
YEAR=2005,
ABSTRACT="IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other
nodes on the link, to determine their link-layer addresses to find routers,
and to maintain reachability information about the paths to active
neighbors. If not secured, NDP is vulnerable to various attacks. This
document specifies security mechanisms for NDP. Unlike those in the
original NDP specifications, these mechanisms do not use IPsec.",
URL="http://www.rfc-editor.org/rfc/rfc3971.txt"
}

@TECHREPORT{rfc3972,
AUTHOR="T. Aura",
TITLE="Cryptographically Generated Addresses {(CGA)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3972,
MONTH=mar,
YEAR=2005,
ABSTRACT="This document describes a method for binding a public signature key to an
IPv6 address in the Secure Neighbor Discovery (SEND) protocol.
Cryptographically Generated Addresses (CGA) are IPv6 addresses for which
the interface identifier is generated by computing a cryptographic one-way
hash function from a public key and auxiliary parameters. The binding
between the public key and the address can be verified by re-computing the
hash value and by comparing the hash with the interface identifier.
Messages sent from an IPv6 address can be protected by attaching the public
key and auxiliary parameters and by signing the message with the
corresponding private key. The protection works without a certification
authority or any security infrastructure.",
URL="http://www.rfc-editor.org/rfc/rfc3972.txt"
}

@TECHREPORT{rfc3973,
AUTHOR="A. G. Adams and J. Nicholas and W. Siadak",
TITLE="Protocol Independent Multicast - Dense Mode {(PIM-DM):} Protocol
Specification (Revised)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3973,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document specifies Protocol Independent Multicast - Dense Mode
(PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying
unicast routing information base to flood multicast datagrams to all
multicast routers. Prune messages are used to prevent future messages from
propagating to routers without group membership information.",
URL="http://www.rfc-editor.org/rfc/rfc3973.txt"
}

@TECHREPORT{rfc3974,
AUTHOR="M. Nakamura and J. Hagino",
TITLE="{SMTP} Operational Experience in Mixed {IPv4/v6} Environments",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3974,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document discusses SMTP operational experiences in IPv4/v6 dual stack
environments. As IPv6-capable SMTP servers are deployed, it has become
apparent that certain configurations of MX records are necessary for stable
dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the
existing problems in the transition period between IPv4 SMTP and IPv6 SMTP.
It also defines operational requirements for stable IPv4/v6 SMTP operation.",
URL="http://www.rfc-editor.org/rfc/rfc3974.txt"
}

@TECHREPORT{rfc3975,
AUTHOR="Ed. G. Huston and Ed. I. Leuca",
TITLE="{OMA-IETF} Standardization Collaboration",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3975,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document describes the standardization collaboration between the Open
Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF).",
URL="http://www.rfc-editor.org/rfc/rfc3975.txt"
}

@TECHREPORT{rfc3976,
AUTHOR="V. K. Gurbani and F. Haerens and V. Rastogi",
TITLE="Interworking {SIP} and Intelligent Network {(IN)} Applications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3976,
MONTH=jan,
YEAR=2005,
ABSTRACT="Public Switched Telephone Network (PSTN) services such as 800-number
routing (freephone), time-and-day routing, credit-card calling, and virtual
private network (mapping a private network number into a public number) are
realized by the Intelligent Network (IN). This document addresses means to
support existing IN services from Session Initiation Protocol (SIP)
endpoints for an IP-host-to-phone call. The call request is originated on a
SIP endpoint, but the services to the call are provided by the data and
procedures resident in the PSTN/IN. To provide IN services in a transparent
manner to SIP endpoints, this document describes the mechanism for
interworking SIP and Intelligent Network Application Part (INAP).",
URL="http://www.rfc-editor.org/rfc/rfc3976.txt"
}

@TECHREPORT{rfc3978,
AUTHOR="Ed. S. Bradner",
TITLE="{IETF} Rights in Contributions",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3978,
MONTH=mar,
YEAR=2005,
ABSTRACT="The IETF policies about rights in Contributions to the IETF are designed to
ensure that such Contributions can be made available to the IETF and
Internet communities while permitting the authors to retain as many rights
as possible. This memo details the IETF policies on rights in Contributions
to the IETF. It also describes the objectives that the policies are
designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces
Section 10 of RFC 2026.",
URL="http://www.rfc-editor.org/rfc/rfc3978.txt"
}

@TECHREPORT{rfc3979,
AUTHOR="Ed. S. Bradner",
TITLE="Intellectual Property Rights in {IETF} Technology",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3979,
MONTH=mar,
YEAR=2005,
ABSTRACT="The IETF policies about Intellectual Property Rights (IPR), such as patent
rights, relative to technologies developed in the IETF are designed to
ensure that IETF working groups and participants have as much information
about any IPR constraints on a technical proposal as possible. The policies
are also intended to benefit the Internet community and the public at
large, while respecting the legitimate rights of IPR holders. This memo
details the IETF policies concerning IPR related to technology worked on
within the IETF. It also describes the objectives that the policies are
designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces
Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2
of RFC 2028, for all purposes, including reference [2] in RFC 2418.",
URL="http://www.rfc-editor.org/rfc/rfc3979.txt"
}

@TECHREPORT{rfc3980,
AUTHOR="M. Krueger and M. Chadalapaka and R. A. Elliott",
TITLE="{T11} Network Address Authority {(NAA)} Naming Format for {iSCSI} Node
Names",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3980,
MONTH=feb,
YEAR=2005,
ABSTRACT="Internet Small Computer Systems Interface (iSCSI) is a SCSI transport
protocol that maps the SCSI family of protocols onto TCP/IP. This document
defines an additional iSCSI node name type format to enable use of the
Network Address Authority (NAA) worldwide naming format defined by the
InterNational Committee for Information Technology Standards (INCITS) T11 -
Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS). This
document updates RFC 3720.",
URL="http://www.rfc-editor.org/rfc/rfc3980.txt"
}

@TECHREPORT{rfc3981,
AUTHOR="A. Newton and M. Sanz",
TITLE="{IRIS:} The Internet Registry Information Service {(IRIS)} Core Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3981,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document describes an application layer client-server protocol for a
framework to represent the query and result operations of the information
services of Internet registries. Specified in the Extensible Markup
Language (XML), the protocol defines generic query and result operations
and a mechanism for extending these operations for specific registry
service needs.",
URL="http://www.rfc-editor.org/rfc/rfc3981.txt"
}

@TECHREPORT{rfc3982,
AUTHOR="A. Newton and M. Sanz",
TITLE="{IRIS:} A Domain Registry (dreg) Type for the Internet Registry Information
Service {(IRIS)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3982,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document describes an Internet Registry Information Service (IRIS)
registry schema for registered DNS information. The schema extends the
necessary query and result operations of IRIS to provide the functional
information service needs for syntaxes and results used by domain
registries and registrars.",
URL="http://www.rfc-editor.org/rfc/rfc3982.txt"
}

@TECHREPORT{rfc3983,
AUTHOR="A. Newton and M. Sanz",
TITLE="Using the Internet Registry Information Service {(IRIS)} over the Blocks
Extensible Exchange Protocol {(BEEP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3983,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document specifies how to use the Blocks Extensible Exchange Protocol
(BEEP) as the application transport substrate for the Internet Registry
Information Service (IRIS).",
URL="http://www.rfc-editor.org/rfc/rfc3983.txt"
}

@TECHREPORT{rfc3984,
AUTHOR="S. Wenger and M. M. Hannuksela and Thomas Stockhammer and M. Westerlund and
D. Singer",
TITLE="{RTP} Payload Format for {H.264} Video",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3984,
MONTH=feb,
YEAR=2005,
ABSTRACT="This memo describes an RTP Payload format for the ITU-T Recommendation
H.264 video codec and the technically identical ISO/IEC International
Standard 14496-10 video codec. The RTP payload format allows for
packetization of one or more Network Abstraction Layer Units (NALUs),
produced by an H.264 video encoder, in each RTP payload. The payload format
has wide applicability, as it supports applications from simple low
bit-rate conversational usage, to Internet video streaming with interleaved
transmission, to high bit- rate video-on-demand.",
URL="http://www.rfc-editor.org/rfc/rfc3984.txt"
}

@TECHREPORT{rfc3985,
AUTHOR="Ed. S. Bryant and Ed. P. Pate",
TITLE="Pseudo Wire Emulation {Edge-to-Edge} {(PWE3)} Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3985,
MONTH=mar,
YEAR=2005,
ABSTRACT="This document describes an architecture for Pseudo Wire Emulation
Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame
Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks
(PSNs) using IP or MPLS. It presents the architectural framework for pseudo
wires (PWs), defines terminology, and specifies the various protocol
elements and their functions.",
URL="http://www.rfc-editor.org/rfc/rfc3985.txt"
}

@TECHREPORT{rfc3986,
AUTHOR="T. Berners-Lee and R. Fielding and L. Masinter",
TITLE="Uniform Resource Identifier {(URI):} Generic Syntax",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3986,
MONTH=jan,
YEAR=2005,
ABSTRACT="A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet. The URI syntax defines
a grammar that is a superset of all valid URIs, allowing an implementation
to parse the common components of a URI reference without knowing the
scheme-specific requirements of every possible identifier. This
specification does not define a generative grammar for URIs; that task is
performed by the individual specifications of each URI scheme.",
URL="http://www.rfc-editor.org/rfc/rfc3986.txt"
}

@TECHREPORT{rfc3987,
AUTHOR="M. Duerst and M. Suignard",
TITLE="Internationalized Resource Identifiers {(IRIs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3987,
MONTH=jan,
YEAR=2005,
ABSTRACT="This document defines a new protocol element, the Internationalized
Resource Identifier (IRI), as a complement to the Uniform Resource
Identifier (URI). An IRI is a sequence of characters from the Universal
Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined,
which means that IRIs can be used instead of URIs, where appropriate, to
identify resources.",
URL="http://www.rfc-editor.org/rfc/rfc3987.txt"
}

@TECHREPORT{rfc3988,
AUTHOR="B. Black and K. Kompella",
TITLE="Maximum Transmission Unit Signalling Extensions for the Label Distribution
Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3988,
MONTH=jan,
YEAR=2005,
ABSTRACT="Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU)
discovery requires that IP routers have knowledge of the MTU for each link
to which they are connected. As currently specified, the Label Distribution
Protocol (LDP) does not have the ability to signal the MTU for a Label
Switched Path (LSP) to the ingress Label Switching Router (LSR). In the
absence of this functionality, the MTU for each LSP must be statically
configured by network operators or by equivalent off-line mechanisms.",
URL="http://www.rfc-editor.org/rfc/rfc3988.txt"
}

@TECHREPORT{rfc3989,
AUTHOR="M. Stiemerling and Juergen Quittek and T. Taylor",
TITLE="Middlebox Communications {(MIDCOM)} Protocol Semantics",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3989,
MONTH=feb,
YEAR=2005,
ABSTRACT="This memo specifies semantics for a Middlebox Communication (MIDCOM)
protocol to be used by MIDCOM agents for interacting with middleboxes such
as firewalls and Network Address Translators (NATs). The semantics
discussion does not include any specification of a concrete syntax or a
transport protocol. However, a concrete protocol is expected to implement
the specified semantics or, more likely, a superset of it. The MIDCOM
protocol semantics is derived from the MIDCOM requirements, from the MIDCOM
framework, and from working group decisions.",
URL="http://www.rfc-editor.org/rfc/rfc3989.txt"
}

@TECHREPORT{rfc3990,
AUTHOR="B. O'Hara and P. Calhoun and J. Kempf",
TITLE="Configuration and Provisioning for Wireless Access Points {(CAPWAP)}
Problem Statement",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3990,
MONTH=feb,
YEAR=2005,
ABSTRACT="This document describes the Configuration and Provisioning for Wireless
Access Points (CAPWAP) problem statement.",
URL="http://www.rfc-editor.org/rfc/rfc3990.txt"
}

@TECHREPORT{rfc3991,
AUTHOR="B. Foster and F. Andreasen",
TITLE="Media Gateway Control Protocol {(MGCP)} Redirect and Reset Package",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3991,
MONTH=feb,
YEAR=2005,
ABSTRACT="The base Media Gateway Control Protocol (MGCP) specification (RFC 3435)
allows endpoints to be redirected one endpoint at a time. This document
provides extensions in the form of a new MGCP package that provides
mechanisms for redirecting and resetting a group of endpoints. It also
includes the ability to more accurately redirect endpoints by allowing a
list of Call Agents to be specified in a preferred order.",
URL="http://www.rfc-editor.org/rfc/rfc3991.txt"
}

@TECHREPORT{rfc3992,
AUTHOR="B. Foster and F. Andreasen",
TITLE="Media Gateway Control Protocol {(MGCP)} Lockstep State Reporting Mechanism",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3992,
MONTH=feb,
YEAR=2005,
ABSTRACT="A Media Gateway Control Protocol (MGCP) endpoint that has encountered an
adverse failure condition (such as being involved in a transient call when
a Call Agent failover occurred) could be left in a lockstep state whereby
events are quarantined but not notified. The MGCP package described in this
document provides a mechanism for reporting these situations so that the
new Call Agent can take the necessary fault recovery procedures.",
URL="http://www.rfc-editor.org/rfc/rfc3992.txt"
}

@TECHREPORT{rfc3993,
AUTHOR="R. Johnson and T. Palaniappan and M. Stapp",
TITLE="{Subscriber-ID} Suboption for the Dynamic Host Configuration Protocol
{(DHCP)} Relay Agent Option",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3993,
MONTH=mar,
YEAR=2005,
ABSTRACT="This memo defines a new Subscriber-ID suboption for the Dynamic Host
Configuration Protocol's (DHCP) relay agent information option. The
suboption allows a DHCP relay agent to associate a stable Subscriber-ID
with DHCP client messages in a way that is independent of the client and of
the underlying physical network infrastructure.",
URL="http://www.rfc-editor.org/rfc/rfc3993.txt"
}

@TECHREPORT{rfc3994,
AUTHOR="Henning Schulzrinne",
TITLE="Indication of Message Composition for Instant Messaging",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=3994,
MONTH=jan,
YEAR=2005,
ABSTRACT="In instant messaging (IM) systems, it is useful to know during an IM
conversation whether the other party is composing a message; e.g., typing
or recording an audio message. This document defines a new status message
content type and XML namespace that conveys information about a message
being composed. The status message can indicate the composition of a
message of any type, including text, voice, or video. The status messages
are delivered to the instant messaging recipient in the same manner as the
instant messages themselves.",
URL="http://www.rfc-editor.org/rfc/rfc3994.txt"
}

@TECHREPORT{rfc4117,
AUTHOR="Gonzalo  Camarillo and Eric W. Burger and Henning Schulzrinne and Arnoud
{van Wijk}",
TITLE="Transcoding Services Invocation in the Session Initiation Protocol {(SIP)}
Using Third Party Call Control (3pcc)",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4117,
MONTH=jun,
YEAR=2005,
ABSTRACT="This document describes how to invoke transcoding services using Session
Initiation Protocol (SIP) and third party call control.  This way of
invocation meets the requirements for SIP regarding transcoding services
invocation to support deaf, hard of hearing and speech-impaired
individuals.",
URL="http://www.rfc-editor.org/rfc/rfc4117.txt"
}

@TECHREPORT{rfc4123,
AUTHOR="Henning Schulzrinne and Charles Agboh",
TITLE="Session Initiation Protocol {(SIP)-H.323} Interworking Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4123,
MONTH=jul,
YEAR=2005,
ABSTRACT="This document describes the requirements for the logical entity known as
the Session Initiation Protocol (SIP)-H.323 Interworking Function 
(SIP-H.323 IWF) that will allow the interworking between SIP and H.323.",
URL="http://www.rfc-editor.org/rfc/rfc4123.txt"
}

@TECHREPORT{rfc4168,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne and Gonzalo Camarillo",
TITLE="The Stream Control Transmission Protocol {(SCTP)} as a Transport for the
Session Initiation Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4168,
MONTH=oct,
YEAR=2005,
ABSTRACT="This document specifies a mechanism for usage of SCTP (the Stream Control
Transmission Protocol) as the transport mechanism between SIP (Session
Initiation Protocol) entities.  SCTP is a new protocol that provides
several features that may prove beneficial for transport between SIP
entities that exchange a large amount of messages, including gateways and
proxies.  As SIP is transport-independent, support of SCTP is a relatively
straightforward process, nearly identical to support for TCP.",
URL="http://www.rfc-editor.org/rfc/rfc4168.txt"
}

@TECHREPORT{rfc4235,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne and Rohan Mahy",
TITLE="An {INVITE-Initiated} Dialog Event Package for the Session Initiation
Protocol {(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4235,
MONTH=nov,
YEAR=2005,
ABSTRACT="This document defines a dialog event package for the SIP Events
architecture, along with a data format used in notifications for this
package.  The dialog package allows users to subscribe to another user and
to receive notification of the changes in state of INVITE-initiated dialog
usages in which the subscribed-to user is involved.",
URL="http://www.rfc-editor.org/rfc/rfc4235.txt"
}

@TECHREPORT{rfc4251,
AUTHOR="Tatu Ylonen and Chris Lonvick",
TITLE="The Secure Shell {({SSH})} Protocol Architecture",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4251,
MONTH=jan,
YEAR=2006,
ABSTRACT="The Secure Shell (SSH) Protocol is a protocol for secure remote login and
other secure network services over an insecure network.  This document
describes the architecture of the SSH protocol, as well as  the notation
and terminology used in SSH protocol documents.  It also discusses the SSH
algorithm naming system that allows local extensions.  The SSH protocol
consists of three major components: The Transport Layer Protocol provides
server authentication, confidentiality, and integrity with perfect forward
secrecy.  The User Authentication Protocol authenticates the client to the
server. The Connection Protocol multiplexes the encrypted tunnel into
several logical channels.  Details of these protocols are described in
separate documents.",
URL="http://www.ietf.org/rfc/rfc4251.txt"
}

@TECHREPORT{rfc4376,
AUTHOR="Petri Koskelainen and Joerg Ott and Henning Schulzrinne and Xiaotao Wu",
TITLE="Requirements for Floor Control Protocols",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4376,
MONTH=feb,
YEAR=2006,
ABSTRACT="Floor control is a means to manage joint or exclusive access to shared
resources in a (multiparty) conferencing environment. Thereby, floor
control complements other functions -- such as conference and media session
setup, conference policy manipulation, and media control -- that are
realized by other protocols.  This document defines the requirements for a
floor control protocol for multiparty conferences in the context of an
existing framework.",
URL="http://www.rfc-editor.org/rfc/rfc4376.txt"
}

@TECHREPORT{rfc4412,
AUTHOR="Henning Schulzrinne and James Polk",
TITLE="Communications Resource Priority for the Session Initiation Protocol
{(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4412,
MONTH=feb,
YEAR=2006,
ABSTRACT={This document defines two new Session Initiation Protocol (SIP) header
fields for communicating resource priority, namely, {"}Resource-Priority{"}
and {"}Accept-Resource-Priority{"}.  The {"}Resource-Priority{"} header
field can influence the behavior of SIP user agents (such as telephone
gateways and IP telephones) and SIP proxies.  It does not directly
influence the forwarding behavior of IP routers.},
URL="http://www.rfc-editor.org/rfc/rfc4412.txt"
}

@TECHREPORT{rfc4435,
AUTHOR="Yuji Nomura and Rod Walsh and Juha-Pekka Luoma and Hitoshi Asaeda and
Henning Schulzrinne",
TITLE="A Framework for the Usage of Internet Media Guides {(IMGs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4435,
MONTH=apr,
YEAR=2006,
ABSTRACT="This document defines a framework for the delivery of Internet Media Guides
(IMGs).  An IMG is a structured collection of multimedia session
descriptions expressed using the Session Description Protocol (SDP), SDPng,
or some similar session description format.  This document describes a
generalized model for IMG delivery mechanisms, the use of existing
protocols, and the need for additional work to create an IMG delivery
infrastructure.",
URL="http://www.rfc-editor.org/rfc/rfc4435.txt"
}

@TECHREPORT{rfc4473,
AUTHOR="Yuji Nomura and Rod Walsh and Juha-Pekka Luoma and Joerg Ott and Henning
Schulzrinne",
TITLE="Requirements for Internet Media Guides {(IMGs)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4473,
MONTH=may,
YEAR=2006,
ABSTRACT="This memo specifies requirements for a framework and protocols for
accessing and updating Internet Media Guide (IMG) information for
media-on-demand and multicast applications.  These requirements are
designed to guide choice and development of IMG protocols for efficient and
scalable delivery.",
URL="http://www.ietf.org/rfc/rfc4473.txt"
}

@TECHREPORT{rfc4475,
AUTHOR="Robert J. Sparks and Alan Hawrylyshen and Alan  Johnston and Jonathan
Rosenberg and Henning Schulzrinne",
TITLE="Session Initiation Protocol {(SIP)} Torture Test Messages",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4475,
MONTH=may,
YEAR=2006,
ABSTRACT={This informational document gives examples of Session Initiation Protocol
(SIP) test messages designed to exercise and {"}torture{"} a SIP
implementation.},
URL="http://www.rfc-editor.org/rfc/rfc4475.txt"
}

@TECHREPORT{rfc4480,
AUTHOR="Henning Schulzrinne and Vijay Gurbani and Paul Kyzivat and Jonathan
Rosenberg",
TITLE="{RPID:} Rich Presence Extensions to the Presence Information Data Format
{(PIDF)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4480,
MONTH=jul,
YEAR=2006,
ABSTRACT="The Presence Information Data Format (PIDF) defines a basic format for
representing presence information for a presentity.  This format defines a
textual note, an indication of availability (open or closed) and a Uniform
Resource Identifier (URI) for communication. The Rich Presence Information
Data format (RPID) described here is an  extension that adds optional
elements to the Presence Information Data Format (PIDF).  These extensions
provide additional information about the presentity and its contacts.  The
information is designed so that much of it can be derived automatically,
e.g., from calendar files or user activity. This extension includes
information about what the person is doing, a grouping identifier for a
tuple, when a service or device was last used, the type of place a person
is in, what media communications might remain private, the relationship of
a service tuple to another presentity, the person's mood, the time zone it
is located in, the type of service it offers, an icon reflecting the
presentity's status, and the overall role of the presentity. These
extensions include presence information for persons, services (tuples), and
devices.",
URL="http://www.rfc-editor.org/rfc/rfc4480.txt"
}

@TECHREPORT{rfc4481,
AUTHOR="Henning Schulzrinne",
TITLE="Timed Presence Extensions to the Presence Information Data Format {(PIDF)}
to Indicate Status Information for Past and Future Time Intervals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4481,
MONTH=jul,
YEAR=2006,
ABSTRACT="The Presence Information Data Format (PIDF) defines a basic XML format for
presenting presence information for a presentity.  This document extends
PIDF, adding a timed status extension (<timed-status> element) that allows
a presentity to declare its status for a time interval fully in the future
or the past.",
URL="http://www.rfc-editor.org/rfc/rfc4481.txt"
}

@TECHREPORT{rfc4482,
AUTHOR="Henning Schulzrinne",
TITLE="{CIPID:} Contact Information for the Presence Information Data Format",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4482,
MONTH=jul,
YEAR=2006,
ABSTRACT="The Presence Information Data Format (PIDF) defines a basic XML format for
presenting presence information for a presentity.  The Contact Information
for the Presence Information Data format (CIPID) is an extension that adds
elements to PIDF that provide additional contact information about a
presentity and its contacts, including references to address book entries
and icons.",
URL="http://www.rfc-editor.org/rfc/rfc4482.txt"
}

@TECHREPORT{rfc4485,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne",
TITLE="Guidelines for Authors of Extensions to the Session Initiation Protocol
{(SIP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4485,
MONTH=may,
YEAR=2006,
ABSTRACT="The Session Initiation Protocol (SIP) is a flexible yet simple tool for
establishing interactive communications sessions across the Internet.  Part
of this flexibility is the ease with which it can be extended.  In order to
facilitate effective and interoperable extensions to SIP, some guidelines
need to be followed when developing SIP extensions.  This document outlines
a set of such guidelines for authors of SIP extensions.",
URL="http://www.rfc-editor.org/rfc/rfc4485.txt"
}

@TECHREPORT{rfc4575,
AUTHOR="Jonathan Rosenberg and Henning Schulzrinne and Orit Levin",
TITLE="A Session Initiation Protocol {(SIP)} Event Package for Conference State",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4575,
MONTH=aug,
YEAR=2006,
ABSTRACT="This document defines a conference event package for tightly coupled
conferences using the Session Initiation Protocol (SIP) events framework,
along with a data format used in notifications for this package.  The
conference package allows users to subscribe to a conference Uniform
Resource Identifier (URI).  Notifications are sent about changes in the
membership of this conference and optionally about changes in the state of
additional conference components.",
URL="http://www.ietf.org/rfc/rfc4575.txt"
}

@TECHREPORT{rfc4589,
AUTHOR="Henning Schulzrinne and Hannes Tschofenig",
TITLE="Location Types Registry",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4589,
MONTH=jul,
YEAR=2006,
ABSTRACT="This document creates a registry for describing the types of places a human
or end system might be found.  The registry is then referenced by other
protocols that need a common set of location terms as protocol constants. 
Examples of location terms defined in this document include aircraft,
office, and train station.",
URL="http://www.rfc-editor.org/rfc/rfc4589.txt"
}

@TECHREPORT{rfc4676,
AUTHOR="Henning Schulzrinne",
TITLE="Dynamic Host Configuration Protocol {(DHCPv4} and {DHCPv6)} Option for
Civic Addresses Configuration Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
MONTH=oct,
YEAR=2006,
ABSTRACT="This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and
DHCPv6) option containing the civic location of the client or the DHCP
server.  The Location Configuration Information (LCI) includes information
about the country, administrative units such as states, provinces, and
cities, as well as street addresses, postal community names, and building
information.  The option allows multiple renditions of the same address in
different scripts and languages.",
URL="http://www.rfc-editor.org/rfc/rfc4676.txt"
}

@TECHREPORT{rfc4733,
AUTHOR="Henning Schulzrinne and Tom Taylor",
TITLE="{RTP} Payload for {DTMF} Digits, Telephony Tones, and Telephony Signals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4733,
MONTH=dec,
YEAR=2006,
ABSTRACT="This memo describes how to carry dual-tone multifrequency (DTMF)
signalling, other tone signals, and telephony events in RTP packets. It
obsoletes RFC 2833. This memo captures and expands upon the basic framework
defined in RFC 2833, but retains only the most basic event codes.  It sets
up an IANA registry to which other event code assignments may be added.
Companion documents add event codes to this registry relating to modem,
fax, text telephony, and channel-associated signalling events. The
remainder of the event codes defined in RFC 2833 are conditionally reserved
in case other documents revive their use. This document provides a number
of clarifications to the original document.  However, it specifically
differs from RFC 2833 by removing the requirement that all compliant
implementations support the DTMF events.  Instead, compliant
implementations taking part in out-of-band negotiations of media stream
content indicate what events they support.  This memo adds three new
procedures to the RFC 2833 framework: subdivision of long events into
segments, reporting of multiple events in a single packet, and the concept
and reporting of state events.",
URL="http://www.rfc-editor.org/rfc/rfc4733.txt"
}

@TECHREPORT{rfc4734,
AUTHOR="Henning Schulzrinne and Tom Taylor",
TITLE="Definition of Events for Modem, Fax, and Text Telephony Signals",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4734,
MONTH=dec,
YEAR=2006,
ABSTRACT="This memo updates RFC 4733 to add event codes for modem, fax, and text
telephony signals when carried in the telephony event RTP payload.  It
supersedes the assignment of event codes for this purpose in RFC 2833, and
therefore obsoletes that part of RFC 2833.",
URL="http://www.rfc-editor.org/rfc/rfc4734.txt"
}

@TECHREPORT{rfc4776,
AUTHOR="Henning Schulzrinne",
TITLE="Dynamic Host Configuration Protocol {(DHCPv4} and {DHCPv6)} Option for
Civic Addresses Configuration Information",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4776,
MONTH=nov,
YEAR=2006,
ABSTRACT="This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and
DHCPv6) option containing the civic location of the client or the DHCP
server.  The Location Configuration Information (LCI) includes information
about the country, administrative units such as states, provinces, and
cities, as well as street addresses, postal community names, and building
information.  The option allows multiple renditions of the same address in
different scripts and languages.",
URL="http://www.rfc-editor.org/rfc/rfc4776.txt"
}

@TECHREPORT{rfc4745,
AUTHOR="Henning Schulzrinne and Hannes Tschofenig and John Morris and Jorge R.
Cuellar and James Polk and Jonathan Rosenberg",
TITLE="Common Policy: A Document Format for Expressing Privacy Preferences",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=4745,
MONTH=feb,
YEAR=2007,
ABSTRACT="This document defines a framework for authorization policies controlling
access to application-specific data.  This framework combines common
location- and presence-specific authorization aspects.  An XML schema
specifies the language in which common policy rules are represented.  The
common policy framework can be extended to other application domains.",
URL="http://www.rfc-editor.org/rfc/rfc4745.txt"
}

@TECHREPORT{rfc5012,
AUTHOR="Henning Schulzrinne and Roger S Marshall",
TITLE="Requirements for Emergency Context Resolution with Internet Technologies",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5012,
DAYS=1,
MONTH=jan,
YEAR=2008,
ABSTRACT="This document defines terminology and enumerates requirements for the
context resolution of emergency calls placed by the public using
voice-over-IP (VoIP) and general Internet multimedia systems, where
Internet protocols are used end to end. This memo provides information for
the Internet community."
}

@TECHREPORT{rfc5031,
AUTHOR="Henning Schulzrinne",
TITLE="A Uniform Resource Name {(URN)} for Emergency and Other {Well-Known}
Services",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5031,
DAYS=1,
MONTH=jan,
YEAR=2008,
ABSTRACT="The content of many communication services depends on the context, such as
the user's location. We describe a 'service' URN that allows well-known
context-dependent services that can be resolved in a distributed manner to
be identified. Examples include emergency services, directory assistance,
and call-before-you-dig hot lines."
}

@TECHREPORT{rfc5069,
AUTHOR="Tom Taylor and Hannes Tschofenig and Henning Schulzrinne and Murugaraj
Shanmugam",
TITLE="Security Threats and Requirements for Emergency Call Marking and Mapping",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5069,
DAYS=1,
MONTH=jan,
YEAR=2008,
ABSTRACT="This document reviews the security threats associated with the marking of
signalling messages to indicate that they are related to an emergency, and
with the process of mapping locations to Universal Resource Identifiers
(URIs) that point to Public Safety Answering Points (PSAPs). This mapping
occurs as part of the process of routing emergency calls through the IP
network.
Based on the identified threats, this document establishes a set of
security requirements for the mapping protocol and for the handling of
emergency-marked calls. This memo provides information for the Internet
community.",
URL="http://www.rfc-editor.org/rfc/rfc5069.txt"
}

@TECHREPORT{rfc5222,
AUTHOR="Ted Hardie and Andrew L. Newton and Henning Schulzrinne and Hannes
Tschofenig",
TITLE="{LoST:} A {Location-to-Service} Translation Protocol",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5222,
DAYS=1,
MONTH=aug,
YEAR=2008,
ABSTRACT="This document describes an XML-based protocol for mapping service
identifiers and geodetic or civic location information to service contact
URIs.  In particular, it can be used to determine the location-appropriate
Public Safety Answering Point (PSAP) for emergency services.",
URL="http://www.rfc-editor.org/rfc/rfc5222.txt"
}

@TECHREPORT{rfc5223,
AUTHOR="Henning Schulzrinne and James Polk and Hannes Tschofenig",
TITLE="Discovering {Location-to-Service} Translation {(LoST)} Servers Using the
Dynamic Host Configuration Protocol {(DHCP)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5223,
DAYS=1,
MONTH=aug,
YEAR=2008,
ABSTRACT="The Location-to-Service Translation (LoST) Protocol describes an XML-based
protocol for mapping service identifiers and geospatial or civic location
information to service contact Uniform Resource Locators (URLs).  LoST
servers can be located anywhere, but a placement closer to the end host,
e.g., in the access network, is desirable.  In disaster situations with
intermittent network connectivity, such a LoST server placement provides
benefits regarding the resiliency of emergency service communication. This
document describes how a LoST client can discover a LoST server using the
Dynamic Host Configuration Protocol (DHCP).",
URL="http://www.rfc-editor.org/rfc/rfc5223.txt"
}

@TECHREPORT{rfc5244,
AUTHOR="Henning Schulzrinne and Tim Taylor",
TITLE="Definition of Events for {Channel-Oriented} Telephony Signalling",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5244,
DAYS=1,
MONTH=jun,
YEAR=2008,
ABSTRACT="This memo updates RFC 4733 to add event codes for telephony signals used
for channel-associated signalling when carried in the telephony event RTP
payload.  It supersedes and adds to the original assignment of event codes
for this purpose in Section 3.14 of RFC 2833.  As documented in Appendix A
of RFC 4733, some of the RFC 2833 events have been deprecated because their
specification was ambiguous, erroneous, or redundant.  In fact, the degree
of change from Section 3.14 of RFC 2833 is such that implementations of the
present document will be fully backward compatible with RFC 2833
implementations only in the case of full ABCD-bit signalling.  This
document expands and improves the coverage of signalling systems compared
to RFC 2833.",
URL="http://www.rfc-editor.org/rfc/rfc5244.txt"
}

@TECHREPORT{rfc5582,
AUTHOR="Henning Schulzrinne",
TITLE="{Location-to-URL} Mapping Architecture and Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5582,
DAYS=1,
MONTH=sep,
YEAR=2009,
ABSTRACT="This document describes an architecture for a global, scalable, resilient,
and administratively distributed system for mapping
geographic location information to URLs, using the Location-to-Service
Translation (LoST) protocol.  The architecture generalizes well-known
approaches found in hierarchical lookup systems such as DNS.",
URL="http://www.rfc-editor.org/rfc/rfc5582.txt"
}

@TECHREPORT{rfc5631,
AUTHOR="Ron Shacham and Henning Schulzrinne and Srisakul Thakolsri and Wolfgang
Kellerer",
TITLE="Session Initiation Protocol {(SIP)} Session Mobility",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5631,
DAYS=1,
MONTH=oct,
YEAR=2009,
ABSTRACT="Session mobility is the transfer of media of an ongoing communication
session from one device to another.  This document describes the basic
approaches and shows the signaling and media flow examples for providing
this service using the Session Initiation Protocol (SIP). Service discovery
is essential to locate targets for session transfer and is discussed using
the Service Location Protocol (SLP) as an example.  This document is an
informational document.",
URL="http://www.rfc-editor.org/rfc/rfc5631.txt"
}

@TECHREPORT{rfc5687,
AUTHOR="Hannes Tschofenig and Henning Schulzrinne",
TITLE="{GEOPRIV} Layer 7 Location Configuration Protocol: Problem Statement and
Requirements",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5687,
DAYS=1,
MONTH=mar,
YEAR=2010,
ABSTRACT="This document provides a problem statement, lists requirements, and
captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration
Protocol (LCP).  This protocol aims to allow an end host to obtain location
information, by value or by reference, from a Location Information Server
(LIS) that is located in the access network.  The obtained location
information can then be used for a variety of different protocols and
purposes.  For example, it can be used as input to the Location-to-Service
Translation (LoST) Protocol or to convey location within the Session
Initiation Protocol (SIP) to other entities.",
URL="http://www.rfc-editor.org/rfc/rfc5687.txt"
}

@TECHREPORT{rfc5765,
AUTHOR="Henning Schulzrinne and Enrico Marocco and Emil Ivov",
TITLE="Security Issues and Solutions in {Peer-to-Peer} Systems for Realtime
Communications",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5765,
DAYS=1,
MONTH=feb,
YEAR=2010,
ABSTRACT="Peer-to-peer (P2P) networks have become popular for certain applications
and deployments for a variety of reasons, including fault tolerance,
economics, and legal issues.  It has therefore become reasonable for
resource consuming and typically centralized applications like Voice over
IP (VoIP) and, in general, realtime communication to adapt and exploit the
benefits of P2P.  Such a migration needs to address a new set of
P2P-specific security problems.  This document describes some of the known
issues found in common P2P networks, analyzing the relevance of such issues
and the applicability of existing solutions when using P2P architectures
for realtime communication.  This document is a product of the P2P Research
Group.",
URL="http://www.rfc-editor.org/rfc/rfc5765.txt"
}

@TECHREPORT{rfc5888,
AUTHOR="Gonzalo  Camarillo and Henning Schulzrinne",
TITLE="The Session Description Protocol {({SDP})} Grouping Framework",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5888,
DAYS=1,
MONTH=jun,
YEAR=2010,
ABSTRACT={In this specification, we define a framework to group {"}m{"} lines in the
Session Description Protocol (SDP) for different purposes.  This framework
uses the {"}group{"} and {"}mid{"} SDP attributes, both of which are
defined in this specification.  Additionally, we specify how to use the
framework for two different purposes: for lip synchronization and for
receiving a media flow consisting of several media streams on different
transport addresses.  This document obsoletes RFC 3388.},
URL="http://www.rfc-editor.org/rfc/rfc5888.txt"
}

@TECHREPORT{rfc5962,
AUTHOR="Henning Schulzrinne and Vishal Kumar Singh and Hannes Tschofenig and Martin
Thomson",
TITLE="Dynamic Extensions to the Presence Information Data Format Location Object
{(PIDF-LO)}",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5962,
DAYS=1,
MONTH=sep,
YEAR=2010,
ABSTRACT="The Geopriv Location Object introduced by the Presence Information Data
Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format
for carrying geographical information of a presentity. This document
defines PIDF-LO extensions to convey information about moving objects. 
Elements are defined that enable expression of spatial orientation, speed,
and heading of the presentity.",
URL="http://www.rfc-editor.org/rfc/rfc5962.txt"
}

@TECHREPORT{rfc5905,
AUTHOR="David L. Mills and Jim Martin and Jack Burbank and William Kasch",
TITLE="Network Time Protocol Version 4: Protocol and Algorithms Specification",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5905,
MONTH=jun,
YEAR=2010,
URL="https://www.rfc-editor.org/info/rfc5905",
}


@TECHREPORT{rfc5971,
AUTHOR="Henning Schulzrinne and Robert E Hancock",
TITLE="{{GIST}:} General Internet Signalling Transport",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5971,
DAYS=1,
MONTH=oct,
YEAR=2010,
ABSTRACT={This document specifies protocol stacks for the routing and transport of
per-flow signalling messages along the path taken by that flow through the
network.  The design uses existing transport and security protocols under a
common messaging layer, the General Internet Signalling Transport (GIST),
which provides a common service for diverse signalling applications.  GIST
does not handle signalling application state itself, but manages its own
internal state and the configuration of the underlying transport and
security protocols to enable the transfer of messages in both directions
along the flow path.  The combination of GIST and the lower layer transport
and security protocols provides a solution for the base protocol component
of the {"}Next Steps in Signalling{"} (NSIS) framework.},
URL="http://www.rfc-editor.org/rfc/rfc5971.txt"
}

@TECHREPORT{rfc5979,
AUTHOR="Charles Shen and Henning Schulzrinne and Sung-Hyuck Lee and Jung Ho  Bang",
TITLE="{NSIS} Operation over {IP} Tunnels",
TYPE="RFC",
INSTITUTION="Internet Engineering Task Force",
NUMBER=5979,
DAYS=1,
MONTH=mar,
YEAR=2011,
ABSTRACT="NSIS Quality of Service (QoS) signaling enables applications to perform QoS
reservation along a data flow path.  When the data flow path contains IP
tunnel segments, NSIS QoS signaling has no effect within those tunnel
segments.  Therefore, the resulting tunnel segments could become the
weakest QoS link and invalidate the QoS efforts in the rest of the
end-to-end path.  The problem with NSIS signaling within the tunnel is
caused by the tunnel encapsulation that masks packets' original IP header
fields.  Those original IP header fields are needed to intercept NSIS
signaling messages and classify QoS data packets.  This document defines a
solution to this problem by mapping end-to-end QoS session requests to
corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS
signaling into the IP tunnel segments.",
URL="http://www.rfc-editor.org/rfc/rfc5979.txt"
}

@TECHREPORT{rfc6252,
AUTHOR="A.  Dutta and V.  Fajardo and Y.  Ohba and K.  Taniuchi and H. 
Schulzrinne",
TITLE="A Framework of Media-Independent Pre-Authentication (MPA) for
Inter-Domain Handover Optimization",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6252,
MONTH=jun,
YEAR=2011,
ABSTRACT="This document describes Media-independent Pre-Authentication
(MPA), a new handover optimization mechanism that addresses the issues
on existing mobility management protocols and mobility optimization
mechanisms to support inter-domain handover. MPA is a mobile- assisted,
secure handover optimization scheme that works over any link layer and
with any mobility management protocol, and is most applicable to
supporting optimization during inter-domain handover. MPA's
pre-authentication, pre-configuration, and proactive handover techniques
allow many of the handoff-related operations to take place before the
mobile node has moved to the new network. We describe the details of all
the associated techniques and their applicability for different
scenarios involving various mobility protocols during inter-domain
handover. We have implemented the MPA mechanism for various
network-layer and application-layer mobility protocols, and we report a
summary of experimental performance results in this document. This
document is a product of the IP Mobility Optimizations (MOBOPTS)
Research Group. This document is not an Internet Standards Track
specification; it is published for informational purposes."
}

@TECHREPORT{rfc6280,
AUTHOR="Richard Barnes and Matt Lepinski and Alissa Cooper and John
Morris and Hannes Tschofenig and Henning Schulzrinne",
TITLE="An Architecture for Location and Location Privacy in Internet Applications",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6280,
MONTH=jul,
YEAR=2011,
ABSTRACT="Location-based services (such as navigation applications,
emergency services, and management of equipment in the field) need
geographic location information about Internet hosts, their users, and
other related entities. These applications need to securely gather and
transfer location information for location services, and at the same
time protect the privacy of the individuals involved. This document
describes an architecture for privacy-preserving location-based services
in the Internet, focusing on authorization, security, and privacy
requirements for the data formats and protocols used by these services.
This memo documents an Internet Best Current Practice."
}

@TECHREPORT{rfc6443,
AUTHOR="Brian Rosen and Henning Schulzrinne and James Polk and Andrew
Newton",
TITLE="Framework for Emergency Calling Using {Internet} Multimedia",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6443,
MONTH=dec,
YEAR=2011,
ABSTRACT="The IETF has standardized various aspects of placing emergency
calls.  This document describes how all of those component parts are
used to support emergency calls from citizens and visitors to
authorities."
}

@TECHREPORT{rfc6451,
AUTHOR="Andrea Forte and Henning Schulzrinne",
TITLE="Location-to-Service Translation ({LoST}) Protocol Extensions",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6451,
MONTH=dec,
YEAR=2011,
ABSTRACT={An important class of location-based services answers the
question, "What instances of this service are closest to me?" Examples
include finding restaurants, gas stations, stores, automated teller
machines, wireless access points (hot spots), or parking spaces. 
Currently, the Location-to-Service Translation (LoST) protocol only
supports mapping locations to a single service based on service regions. 
This document describes an extension that allows queries of the type "N
nearest", "within distance X", and "served by".}
}

@TECHREPORT{rfc6503,
AUTHOR="Mary Barnes and Chris Boulton and Simon Pietro Romano and
Henning Schulzrinne",
TITLE="Centralized Conferencing Manipulation Protocol",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6503,
MONTH=mar,
YEAR=2012,
ABSTRACT=" The Centralized Conferencing Manipulation Protocol (CCMP)
allows a Centralized Conferencing (XCON) system client to create,
retrieve, change, and delete objects that describe a centralized
conference.  CCMP is a means to control basic and advanced conference
features such as conference state and capabilities, participants,
relative roles, and details.  CCMP is a stateless, XML-based, client
server protocol that carries, in its request and response messages,
conference information in the form of XML documents and fragments
conforming to the centralized conferencing data model schema."
}

@TECHREPORT{rfc6739,
AUTHOR="Henning Schulzrinne and Hannes Tschofenig",
TITLE="Synchronizing Service Boundaries and $<$mapping$>$ Elements Based on the
Location-to-Service Translation ({LoST}) Protocol",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6739,
MONTH=oct,
YEAR=2012,
ABSTRACT="The Location-to-Service Translation (LoST) protocol is an
XML-based protocol for mapping service identifiers and geodetic or civic
location information to service URIs and service boundaries.  In
particular, it can be used to determine the location-appropriate Public
Safety Answering Point (PSAP) for emergency services.

The <mapping> element in the LoST protocol specification encapsulates
information about service boundaries and circumscribes the region within
which all locations map to the same service Uniform Resource Identifier
(URI) or set of URIs for a given service.

This document defines an XML protocol to exchange these mappings between
two nodes.  This mechanism is designed for the exchange of authoritative
<mapping> elements between two entities.  Exchanging cached <mapping>
elements, i.e., non-authoritative elements, is possible but not
envisioned.  Even though the <mapping> element format is reused from the
LoST specification, the mechanism in this document can be used without
the LoST protocol."
}

@TECHREPORT{rfc6753,
AUTHOR="James Winterbottom and Hannes Tschofenig and Henning Schulzrinne
and Martin Thomson",
TITLE="A Location Dereference Protocol Using {HTTP}-Enabled Location
Delivery ({HELD})",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6753,
MONTH=oct,
YEAR=2012,
ABSTRACT="This document describes how to use the Hypertext Transfer
Protocol (HTTP) over Transport Layer Security (TLS) as a dereference
protocol to resolve a reference to a Presence Information Data Format
Location Object (PIDF-LO).  This document assumes that a Location
Recipient possesses a URI that can be used in conjunction with the
HTTP-Enabled Location Delivery (HELD) protocol to request the location
of the Target."
}

@TECHREPORT{rfc6772,
AUTHOR="Henning Schulzrinne and Hannes Tschofenig and Jorge R. Cuellar
and James Polk and John B. Morris and Martin Thomason",
TITLE="Geolocation Policy:  A Document Format for Expressing Privacy
Preferences for Location Information",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6772,
MONTH=jan,
YEAR=2013,
ABSTRACT="This document defines an authorization policy language for
controlling access to location information.  It extends the Common
Policy authorization framework to provide location-specific access
control.  More specifically, this document defines condition elements
specific to location information in order to restrict access to data
based on the current location of the Target.

Furthermore, this document defines two algorithms for reducing the
granularity of returned location information.  The first algorithm is
defined for usage with civic location information, whereas the other one
applies to geodetic location information.  Both algorithms come with
limitations.  There are circumstances where the amount of location
obfuscation provided is less than what is desired.  These algorithms
might not be appropriate for all application domains."
}

@TECHREPORT{rfc6940,
AUTHOR="Cullen Jennings and Bruce Lowekamp and Eric Rescorla and Salman Baset
and Henning Schulzrinne",
TITLE="REsource LOcation And Discovery ({RELOAD}) Base Protocol",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=6940,
MONTH=jan,
YEAR=2014,
ABSTRACT={This specification defines REsource LOcation And Discovery
(RELOAD), a peer-to-peer (P2P) signaling protocol for use on the
Internet.  A P2P signaling protocol provides its clients with an
abstract storage and messaging service between a set of cooperating
peers that form the overlay network.  RELOAD is designed to support a
P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by
other applications with similar requirements by defining new usages that
specify the Kinds of data that need to be stored for a particular
application.  RELOAD defines a security model based on a certificate
enrollment service that provides unique identities.  NAT traversal is a
fundamental service of the protocol.  RELOAD also allows access from
"client" nodes that do not need to route traffic or store data for
others.}
}

@TECHREPORT{rfc7090,
AUTHOR="Henning Schulzrinne and Hannes Tschofenig and
Christer Holmberg and Milan Patel",
TITLE="Public Safety Answering Point ({PSAP}) Callback",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7090,
MONTH=apr,
YEAR=2014,
ABSTRACT="After an emergency call is completed (terminated either
prematurely by the emergency caller or normally by the call taker), the
call taker may feel the need for further communication.  For example,
the call may have been dropped by accident without the call taker having
sufficient information about the current state of an accident victim.  A
call taker may trigger a callback to the emergency caller using the
contact information provided with the initial emergency call.  This
callback could, under certain circumstances, be treated like any other
call and, as a consequence, it may get blocked by authorization policies
or may get forwarded to an answering machine.  The IETF emergency
services architecture specification already offers a solution approach
for allowing Public Safety Answering Point (PSAP) callbacks to bypass
authorization policies in order to reach the caller without unnecessary
delays.  Unfortunately, the specified mechanism only supports limited
scenarios.  This document discusses shortcomings of the current
mechanisms and illustrates additional scenarios where better-than-normal
call treatment behavior would be desirable.  We describe a solution
based on a new header field value for the SIP Priority header field,
called 'psap-callback', to mark PSAP callbacks."
}

@TECHREPORT{rfc7200,
AUTHOR="Charles Shen and Henning Schulzrinne and Arata Koike",
TITLE="A Session Initiation Protocol ({SIP}) Load-Control Event Package",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7200,
MONTH=apr,
YEAR=2014,
ABSTRACT="This specification defines a load-control event package for
the Session Initiation Protocol (SIP).  It allows SIP entities to
distribute load-filtering policies to other SIP entities in the network. 
The load-filtering policies contain rules to throttle calls from a
specific user or based on their source or destination domain, telephone
number prefix.  The mechanism helps to prevent signaling overload and
complements feedback-based SIP overload control efforts."
}

@TECHREPORT{rfc7339,
AUTHOR="Vijay Gurbani and Volker Hilt and Henning Schulzrinne",
TITLE="{Session Initiation Protocol} ({SIP}) Overload Control",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7339,
MONTH=sep,
YEAR=2014,
ABSTRACT="Overload occurs in Session Initiation Protocol (SIP) networks
when SIP servers have insufficient resources to handle all the SIP
messages they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document defines the behavior of SIP servers involved in overload
control and also specifies a loss-based overload scheme for SIP.",
}

@TECHREPORT{rfc7340,
AUTHOR="Jon Peterson and Henning Schulzrinne and Hannes Tschofenig",
TITLE="Secure Telephone Identity Problem Statement and Requirements",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7340,
MONTH=sep,
YEAR=2014,
ABSTRACT="Over the past decade, Voice over IP (VoIP) systems based on
SIP have replaced many traditional telephony deployments. Interworking
VoIP systems with the traditional telephone network has reduced the
overall level of calling party number and Caller ID assurances by
granting attackers new and inexpensive tools to impersonate or obscure
calling party numbers when orchestrating bulk commercial calling
schemes, hacking voicemail boxes, or even circumventing multi-factor
authentication systems trusted by banks. Despite previous attempts to
provide a secure assurance of the origin of SIP communications, we still
lack effective standards for identifying the calling party in a VoIP
session. This document examines the reasons why providing identity for
telephone numbers on the Internet has proven so difficult and shows how
changes in the last decade may provide us with new strategies for
attaching a secure identity to SIP sessions. It also gives high-level
requirements for a solution in this space."
}

@TECHREPORT{rfc7378,
AUTHOR="Hannes Tschofenig and Henning Schulzrinne and Bernd Aboba",
TITLE="Trustworthy Location",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7378,
MONTH=dec,
YEAR=2014,
ABSTRACT="The trustworthiness of location information is critically
important for some location-based applications, such as emergency
calling or roadside assistance. This document describes threats to
conveying location, particularly for emergency calls, and describes
techniques that improve the reliability and security of location
information. It also provides guidelines for assessing the
trustworthiness of location information."
}

@TECHREPORT{rfc7406,
AUTHOR="Henning Schulzrinne and Stephen McCann and Gabor Bajko and Hannes
Tschofenig and Dirk Kroeselberg",
TITLE="Extensions to the Emergency Services Architecture for Dealing
With Unauthenticated and Unauthorized Devices",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7406,
MONTH=dec,
YEAR=2014,
ABSTRACT="This document provides a problem statement, introduces
terminology, and describes an extension for the base IETF emergency
services architecture to address cases where an emergency caller is not
authenticated, has no identifiable service provider, or has no remaining
credit with which to pay for access to the network."
}

@TECHREPORT{rfc7826,
AUTHOR="Henning Schulzrinne and Anup Rao and Rob Lanphier and Magnus
Westerlund and Martin Stiemerling",
TITLE="Real-Time Streaming Protocol Version 2.0",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7826,
MONTH=dec,
YEAR=2016,
ABSTRACT="This memorandum defines the Real-Time Streaming Protocol
(RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC
2326. RTSP is an application-layer protocol for the setup and control of
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 3550)."
}

@TECHREPORT{rfc7904,
AUTHOR="Cullen Jennings and Bruce Lowekamp and Eric Rescorla and Salman
Baset and Henning Schulzrinne and Thomas Schmidt",
TITLE="A {SIP} Usage for {REsource LOcation And Discovery (RELOAD)}",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=7904,
MONTH=oct,
YEAR=2016,
ABSTRACT="This document defines a SIP Usage for REsource LOcation And
Discovery (RELOAD).  The SIP Usage provides the functionality of a SIP
proxy or registrar in a fully distributed system and includes a lookup
service for Address of Records (AORs) stored in the overlay.  It also
defines Globally Routable User Agent URIs (GRUUs) that allow the
registrations to map an AOR to a specific node reachable through the
overlay.  After such initial contact of a Peer, the RELOAD AppAttach
method is used to establish a direct connection between nodes through
which SIP messages are exchanged.",
}

@TECHREPORT{rfc8197,
AUTHOR="Henning Schulzrinne",
TITLE="A {SIP} Response Code for Unwanted Calls",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=8197,
MONTH=jul,
YEAR=2017,
ABSTRACT="This document defines the 607 (Unwanted) SIP response code, allowing
called parties to indicate that the call or message was unwanted.
SIP entities may use this information to adjust how future calls from
this calling party are handled for the called party or more broadly.",
}

@TECHREPORT{rfc8520,
AUTHOR="Eliot Lear and Ralph Droms and Dan Romascanu", 
TITLE="Manufacturer Usage Description Specification",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=8520,
MONTH=mar,
YEAR=2019,
ABSTRACT="This memo specifies a component-based architecture for Manufacturer
Usage Descriptions (MUDs).  The goal of MUD is to provide a means for
end devices to signal to the network what sort of access and network
functionality they require to properly function.  The initial focus
is on access control.  Later work can delve into other aspects.
This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a
Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate
extension, and a means to sign and verify the descriptions."
}


@TECHREPORT{rfc8876,
AUTHOR="Brian Rosen and Hennning Schulzrinne and Hannes Tschofenig and Richard Gellens",
TITLE="Non-interactive Emergency Calls",
TYPE="Request for Comments",
INSTITUTION="Internet Engineering Task Force",
NUMBER=8876,
MONTH=sep,
YEAR=2020,
ABSTRACT="Use of the Internet for emergency calling is described in RFC 6443,
'Framework for Emergency Calling Using Internet Multimedia'.  In some
cases of emergency calls, the transmission of application data is all
that is needed, and no interactive media channel is established: a
situation referred to as 'non-interactive emergency calls', where,
unlike most emergency calls, there is no two-way interactive media
such as voice or video or text.  This document describes use of a SIP
MESSAGE transaction that includes a container for the data based on
the Common Alerting Protocol (CAP).  That type of emergency request
does not establish a session, distinguishing it from SIP INVITE,
which does.  Any device that needs to initiate a request for
emergency services without an interactive media channel would use the
mechanisms in this document."
}