Computer And Network SCIENCE

Building Interactive User Interfaces with Microsoft ASP.NET AJAX: AJAX Basics and Getting Started with Microsoft's ASP.NET AJAX Framework

 

Introduction
Over the past several years web developers have started using JavaScript to make asynchronous postbacks to the web server that only transmit and receive the necessary data; these techniques are commonly referred to as AJAX. When properly implemented, AJAX-enabled web applications offer a highly interactive user interface whose responsiveness rivals that of desktop applications. Popular web applications like the social networking news site Digg and GMail are prime examples of AJAX techniques in action.

Since AJAX involves many disparate technologies at different layers in the networking stack, implementing AJAX without the use of an AJAX framework is difficult and error-prone. Fortunately, Microsoft has released a free AJAX framework for ASP.NET developers: Microsoft ASP.NET AJAX. This article is the first in a series of articles that examines the ASP.NET AJAX framework. This installment provides an overview of AJAX technologies and looks at getting started with Microsoft's framework. Future installments will focus on specific controls and scenarios. Read on to learn more!

A Brief History of Ajax
The client-server model is an architecture that involes two actors: a client and a server. The server passively waits for a request from a client and, upon receiving such a request, processes it and returns a reply. The client is responsible for initiating requests to the server, after which is waits for and then processes the data returned in the response. Web applications are classic examples of the client-server model. The client - a web browser, most often - sends a request to a web server for a particular resource. The resource may be static content like an HTML page or an image that the web server can simply return, or it may be dynamic content like an ASP.NET page that must first be processed on the web server before its generated markup can be sent back. Regardless, the interaction is the same: the client requests a particular resource, and the server returns it, be it the binary content of a JPG image or the HTML of a rendered ASP.NET page.

One drawback of the client-server models is latency. Clients must periodically communicate with the server to update the server with the user's input, or to retrieve the latest data from the server. During these periods, the user must wait while the request/response lifecycle plays out. This delay is most clearly evidenced in ASP.NET applications when a postback occurs. Imagine an eCommerce website that lists products in a grid whose contents can be sorted and paged through. However, stepping to the next page requires a postback to the server in order to retrieve the next page of products. Consequently, moving to the next page introduces a delay in the user experience that can take anywhere from less than a second to several seconds, depending on many factors (the user's Internet connection speed, the network congestion, the server load, the database query duration, and so on).

The main culprit here is that the postback requires that all of the page's form fields be sent back to the server and that the entire web page's content be returned to the browser. This volume of exchanged data is overkill since all that is really needed by the client is information about the next page of products. AJAX mitigates these latency issues by using JavaScript to make asynchronous postbacks to the web server; these postbacks transmit and receive the minimum amount of data necessary to perform the requested operation. For a more thorough background of AJAX, be sure to read Jesse James Garrett's essay where he coined the term "Ajax": Ajax: A New Approach to Web Applications.

There are a number of AJAX frameworks available. Most ASP.NET control vendors offer commercial AJAX implementations, and there are many open source libraries as well. In early 2006 Microsoft released its own AJAX framework, Microsoft ASP.NET AJAX, which is the focus of this article series.

An Overview of Microsoft ASP.NET AJAX
Microsoft's ASP.NET AJAX framework was designed to work with ASP.NET 2.0 and future versions; it does not work with ASP.NET version 1.x applications. The ASP.NET AJAX framework will ship with Visual Studio 2008 and ASP.NET version 3.5. ASP.NET 2.0 developers, however, need to download and install the framework from Microsoft's website; the "Getting Started with Microsoft ASP.NET AJAX" section later in this article includes a discussion on installing ASP.NET AJAX in a 2.0 environment.

The ASP.NET AJAX framework consists of client-side and server-side logic. There are a bevy of JavaScript libraries that simplify initiating an asychronous postback and processing the response from the server. The client-side libraries also include classes that mimic the .NET Framework's core classes and data types. The server-side components include ASP.NET controls that, when added to a page, implement various AJAX techniques. One such example is the ScriptManager control, which adds references to the client-side script in the page, so that the browser requesting the ASP.NET page downloads the appropriate JavaScript libraries as well. Consequently, you'll use the ScriptManager on any ASP.NET page where you want to utilize the ASP.NET AJAX framework.

In addition to the ScriptManager control, the ASP.NET AJAX framework includes a handful of other server-side controls, such as the UpdatePanel, the Timer, and the UpdateProgress controls. The UpdatePanel control allows you to define a portion of the page that will be updated by an asynchronous request. In short, it allows you to make partial postbacks rather than a full page postback. This improves the responsiveness of the page in two ways: first, when a partial postback occurs only the data relevant to that UpdatePanel is sent to the server, and only the corresponding data is returned; and, second, the partial page postback does not cause the entire page to be "re-drawn" by the browser, so there's no "flash" that is all too common when making full postbacks.

The UpdatePanel is one of the core pieces of the ASP.NET AJAX framework, and one which we will be examining later on in this article. Once an UpdatePanel has been added to a page, you can add the standard ASP.NET web controls - TextBoxes, Buttons, GridViews, DropDownLists, and so on - and they will automatically take advantage of AJAX techniques. For example, if you have a Button and a TextBox in an UpatePanel and the Button is clicked, a partial postback will occur. The Button's Click event handler will be called on the server-side, as expected, and the value of the TextBox's Text property can be accessed as usual. Moreover, any other Web controls within the same UpdatePanel can have their properties read or assigned and they will be re-rendered and their output updated in the user's browser.

In addition to the base server-side controls (the ScriptManager, UpdatePanel, Timer, and so on), Microsoft offers an additional set of interactive controls via the AJAX Control Toolkit. This toolkit includes ratings controls, sliders, modal popup windows, and so forth.

Getting Started with Microsoft ASP.NET AJAX
For ASP.NET 2.0 developers, the first step in working with Microsoft ASP.NET AJAX is to download the AJAX Extensions and, optionally, the AJAX Control Toolkit. (ASP.NET 3.5 developers will already have the ASP.NET AJAX framework installed.)

   Note: This article only looks at working with the AJAX Extensions (the core of the framework) and leaves the Control Toolkit for a future installment.

To download the ASP.NET AJAX 1.0 framework, visit this page and click the Download button. The ASP.NET AJAX framework is packaged up as an MSI file. Once you've downloaded the MSI file to your computer, double-click it to install the framework. After downloading and installing the ASP.NET AJAX framework, start Visual Studio and choose to create a New Project. In the New Project dialog box you should see a new project type named "ASP.NET AJAX-Enabled Web Application."

Creating an ASP.NET AJAX-Enabled Web Application creates a new Web Application Project with the System.Web.Extensions assembly added as a reference. The System.Web.Extensions assembly contains the core client- and server-side pieces of Microsoft's ASP.NET AJAX framework. Also, the Toolbox includes an AJAX Extensions category with the core server-side AJAX controls.

Our First ASP.NET AJAX Example: Using the UpdatePanel
The UpdatePanel is useful in situations where you only want a portion of the page to postback rather than the entire page. Such a limited postback is called a partial postback, and is easy to implement using the UpdatePanel. As you know, many ASP.NET controls can cause postbacks: Button controls, when clicked; DropDownLists and CheckBoxes, when their AutoPostBack property is set to True; and so on. Under normal circumstances, when these controls cause a postback, the entire page is posted back. All form field values are sent from the browser to the server. The server then re-renders the entire page and returns the complete HTML, which is then redisplayed by the browser.

When these controls appear in an UpdatePanel, however, a partial page postback is initiated instead. Only the form fields in the UpdatePanel are sent to the server. The server then re-renders the page, but only sends back the markup for those controls in the UpdatePanel. The client-side script that initiated the partial postback receives the partial markup results from the server and seamlessly updates the display in the browser with the returned values. Consequently, the UpdatePanel improves the reponsiveness of a page by reducing the amount of data exchanged between the client and the server and by "redrawing" only the portion of the screen that kicked off the partial page postback.

Let's take a look at the UpdatePanel in action. The following demo, which is downloadable at the end of this article, shows a simple example. The UpdatePanel in the demo includes only two controls: a Label and a Button. The Label Web control displays the text of a randomly selected joke. Clicking the Button loads a new randomly selected joke into the Label. If you are following along at your computer, start by adding a new ASP.NET page to the ASP.NET AJAX-Enabled Web Application we created back in the "Getting Started with Microsoft ASP.NET AJAX" section.

Whenever we use the ASP.NET AJAX framework in a page, we need to start by adding a ScriptManager control, so start by adding a ScriptManager to the page. Next, add an UpdatePanel to the page. Within that UpdatePanel, add a Label control and a Button control. After performing these steps, the declarative markup in your web page should look similar to the following:

Font-Size="Large">

At this point, all that remains is to write the server-side code. When the page is first loaded we want to set the JokeText Label's Text property to a randomly selected joke; likewise, whenever the NewJokeButton is clicked, we want to refresh the Label's Text property with a new joke.

protected void Page_Load(object sender, EventArgs e) {     JokeText.Text = GetRandomJoke(); } protected void NewJokeButton_Click(object sender, EventArgs e) {     JokeText.Text = GetRandomJoke(); } private string GetRandomJoke() {     // Get a random number     Random r = new Random();     switch (r.Next(5))     {        case 0:             return "Why did the chicken cross the road? To get to the other side!!";        case 1:             return "How much do pirates pay for their earrings? A Buccaneer!";        case 2:             return "Why did the computer squeak? Because someone stepped on it's mouse!";        case 3:             return "What is a golfer's favorite letter? Tee!";        default:             return "A child comes home from his first day at school. Mom asks, \"What did you learn today?\" \"Not enough,\" the kid replies, \"I have to go back tomorrow.\"";     } }

At this point we have a page that will utilize AJAX techniques to make a partial page postback when the Button in the UpdatePanel is clicked. Consequently, clicking the "Show Me a Random Joke!" button displays a new joke promptly without having the entire page refresh. Granted, this is an overly simple example since the page already is very lightweight, but this concept can be extended to more real-world scenarios (and will be, in future installments of this article series). For example, you might have a page that has several grids on it showing a plethora of data. You could place each grid in its own UpdatePanel. That way, when a user sorted or paged a grid, a partial postback would occur and the particular grid could be paged or sorted without requiring a full postback.

The takeaway here is that implementing AJAX techniques in an ASP.NET application using the ASP.NET AJAX framework is remarkably easy. The ScriptManager and UpdatePanel controls automatically handle all of the complexities involved with initiating the asynchronous postback and displaying the returned data.

Looking Forward...
This article only looked at a simple UpdatePanel example. In real-world scenarios, however, things aren't always as simple. For example, we might want to have some event external to the UpdatePanel trigger a partial postback. We've not yet looked at working directly with the client-side AJAX libraries; nor have we explored the wealth of controls in the AJAX Control Toolkit. These, and many more topics, will be the focus of future articles in this series. Until then...

Happy Programming!

 

AN EFFICIENT ALGORITHM FOR LEARNING TRANSLATION INVARIANT

DICTIONARIES

 

ABSTRACT

The performances of approximation using redundant expansions rely on having dictionaries adapted to the signals. In natural high-dimensional data, the statistical dependencies are, most of the time, not obvious. Learning fundamental patterns is an alternative to analytical design of bases and is nowadays a popular problem in the field of approximation theory. In many situations, the basis elements are shift invariant, thus the learning should try to find the best matching filters. We present a new algorithm for learning iteratively generating functions that can be translated at all positions in the signalto generate a highly redundant dictionary.

 INTRODUCTION AND MOTIVATION  

The tremendous activity in the field of sparse approximation [1,2, 3] is partly motivated by the potential of the related techniques for typical tasks in signal processing such as analysis, dimensionality reduction, de-noising or compression. Given a signal s of support of size S in a space of infinite size discrete signals, the central problem is the following: compute a good approximation ~sN as a linear superposition of N basic elements picked up in a huge collection of signals

D = fÁkg, referred to as a dictionary :

~sN =

NX¡1

k=0

ckÁk; Ák 2 D ; ks ¡ ~sNk2 · ² : (1)

The approximant ~sN is sparse when N ¿ S. The main advantage of this class of techniques is the complete freedom in designing the dictionary, which can then be efficiently tailored

to closely match signal structures [4, 5, 6, 7, 8]. The properties of the signal, dictionary and algorithm, are tightly linked. Often, natural signals have highly complex underlying structures which makes it difficult to explicitly define the link between a class of signals and a dictionary. This paper presents a learning algorithm that tries to capture the underlying

structures. In our approach, instead of considering atoms Ák having the same support as the signal s, we propose to learn small generating functions, each of them defining a set of atoms corresponding to all its translations. This is notably motivated by the fact that natural signals often exhibit statistical properties invariant to translation, and that using generating functions allows to generate huge dictionaries while using only few parameters. In addition, fast convolution algorithms can be used to compute the scalar products when using pursuit algorithms. The proposed algorithm learns the generating functions successively and can be stopped when a sufficient number of atoms have been found. First, we formalize the problem of learning generating functions, and we propose an iterative algorithm to learn successively some adapted atoms, with a constraint on their decorrelation. The following section presents the influence of this constraint on the recovery of underlying atoms, depending on their correlation. A second experiment shows the ability of this learning method to give an efficient dictionary for sparse approximations. We also show that this algorithm recovers the atoms typically learned by other methods on natural images. We then conclude on the benefits of this new approach and

list the perspectives we will consider

---

 

ادامه مطلب

Dictionary Of Network

 

Dictionary of Network.pdf ( E_Book ) For Download

 

 

 

 

 

 

 

 

Network Troubleshooting Tools 

OReilly - Network Troubleshooting Tools.pdf ( E_Book) For Download

 

Beejs Guide to Network Programming

Beejs Guide to Network Programming.pdf (E_Book) For Download

 

Wrox.Professional.Java.Development.with.the.Spring.Framework

Wrox.Professional.Java.Development.with.the.Spring.Framework.pdf (E_Book) For Download

 

 

FGH 

 

 

 

Introduction to IP Version 6

 

Microsoft Corporation

Published: September 2003

 

 

 

 

Abstract

Due to recent concerns over the impending depletion of the current pool of Internet addresses and the desire to provide additional functionality for modern devices, an upgrade of the current version of the Internet Protocol (IP), called IPv4, is in the process of standardization. This new version, called IP Version 6 (IPv6), resolves unanticipated IPv4 design issues and takes the Internet into the 21^st Century. This paper describes the problems of the IPv4 Internet and how they are solved by IPv6, IPv6 addressing, the new IPv6 header and its extensions, the IPv6 replacements for the Internet Control Message Protocol (ICMP) and Internet Group Management Protocol (IGMP), neighboring node interaction, and IPv6 address autoconfiguration. This paper provides a foundation of Internet standards-based IPv6 concepts and is intended for network engineers and support professionals who are already familiar with basic networking concepts and TCP/IP.

 

 

 

 

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document  is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2003 Microsoft Corporation. All rights reserved.

Microsoft, MSN, Windows, Windows NT, Windows Server, and the Windows logo are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

 

 

ادامه مطلب

Network Working Group                                          D. Libes
Request for Comments: 1178                Integrated Systems Group/NIST
FYI: 5                                                      August 1990

                   Choosing a Name for Your Computer

Status of this Memo

   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 [1].  This memo provides information for the Internet
   community.  It does not specify any standard.

   Distribution of this memo is unlimited.

Abstract

   In order to easily distinguish between multiple computers, we give
   them names.  Experience has taught us that it is as easy to choose
   bad names as it is to choose good ones.  This essay presents
   guidelines for deciding what makes a name good or bad.

   Keywords: domain name system, naming conventions, computer
   administration, computer network management

Introduction

   As soon as you deal with more than one computer, you need to
   distinguish between them.  For example, to tell your system
   administrator that your computer is busted, you might say, "Hey Ken.
   Goon is down!"

   Computers also have to be able to distinguish between themselves.
   Thus, when sending mail to a colleague at another computer, you might
   use the command "mail libes@goon".

   In both cases, "goon" refers to a particular computer.  How the name
   is actually dereferenced by a human or computer need not concern us
   here.  This essay is only concerned with choosing a "good" name.  (It
   is assumed that the reader has a basic understanding of the domain
   name system as described by [2].)

   By picking a "good" name for your computer, you can avoid a number of
   problems that people stumble over again and again.

   Here are some guidelines on what NOT to do.

 

Libes                                                           [Page 1]

RFC 1178                   Name Your Computer                August 1990

      Don't overload other terms already in common use.

         Using a word that has strong semantic implications in the
         current context will cause confusion.  This is especially true
         in conversation where punctuation is not obvious and grammar is
         often incorrect.

         For example, a distributed database had been built on top of
         several computers.  Each one had a different name.  One machine
         was named "up", as it was the only one that accepted updates.
         Conversations would sound like this: "Is up down?"  and "Boot
         the machine up." followed by "Which machine?"

         While it didn't take long to catch on and get used to this
         zaniness, it was annoying when occasionally your mind would
         stumble, and you would have to stop and think about each word
         in a sentence.  It is as if, all of a sudden, English has
         become a foreign language.

      Don't choose a name after a project unique to that machine.

         A manufacturing project had named a machine "shop" since it was
         going to be used to control a number of machines on a shop
         floor.  A while later, a new machine was acquired to help with
         some of the processing.  Needless to say, it couldn't be called
         "shop" as well.  Indeed, both machines ended up performing more
         specific tasks, allowing more precision in naming.  A year
         later, five new machines were installed and the original one
         was moved to an unrelated project.  It is simply impossible to
         choose generic names that remain appropriate for very long.

         Of course, they could have called the second one "shop2" and so
         on.  But then one is really only distinguishing machines by
         their number.  You might as well just call them "1", "2", and
         "3".  The only time this kind of naming scheme is appropriate
         is when you have a lot of machines and there are no reasons for
         any human to distinguish between them.  For example, a master
         computer might be controlling an array of one hundred
         computers.  In this case, it makes sense to refer to them with
         the array indices.

         While computers aren't quite analogous to people, their names
         are.  Nobody expects to learn much about a person by their
         name.  Just because a person is named "Don" doesn't mean he is
         the ruler of the world (despite what the "Choosing a Name for
         your Baby" books say).  In reality, names are just arbitrary
         tags.  You cannot tell what a person does for a living, what
         their hobbies are, and so on.

 

Libes                                                           [Page 2]

RFC 1178                   Name Your Computer                August 1990

      Don't use your own name.

         Even if a computer is sitting on your desktop, it is a mistake
         to name it after yourself.  This is another case of
         overloading, in which statements become ambiguous.  Does "give
         the disk drive to don" refer to a person or computer?

         Even using your initials (or some other moniker) is
         unsatisfactory.  What happens if I get a different machine
         after a year?  Someone else gets stuck with "don" and I end up
         living with "jim".  The machines can be renamed, but that is
         excess work and besides, a program that used a special
         peripheral or database on "don" would start failing when it
         wasn't found on the "new don".

         It is especially tempting to name your first computer after
         yourself, but think about it.  Do you name any of your other
         possessions after yourself?  No.  Your dog has its own name, as
         do your children.  If you are one of those who feel so inclined
         to name your car and other objects, you certainly don't reuse
         your own name.  Otherwise you would have a great deal of
         trouble distinguishing between them in speech.

         For the same reason, it follows that naming your computer the
         same thing as your car or another possession is a mistake.

      Don't use long names.

         This is hard to quantify, but experience has shown that names
         longer than eight characters simply annoy people.

         Most systems will allow prespecified abbreviations, but why not
         choose a name that you don't have to abbreviate to begin with?
         This removes any chance of confusion.

      Avoid alternate spellings.

         Once we called a machine "czek".  In discussion, people
         continually thought we were talking about a machine called
         "check".  Indeed, "czek" isn't even a word (although "Czech"
         is).

         Purposely incorrect (but cute) spellings also tend to annoy a
         large subset of people.  Also, people who have learned English
         as a second language often question their own knowledge upon
         seeing a word that they know but spelled differently.  ("I
         guess I've always been spelling "funxion" incorrectly.  How
         embarrassing!")

ادامه مطلب

Network Working Group                                          A. Marine
Request for Comments: 1594                                     NASA NAIC
FYI: 4                                                       J. Reynolds
Obsoletes: 1325                                                      ISI
Category: Informational                                        G. Malkin
                                                                Xylogics
                                                              March 1994

                      FYI on Questions and Answers
        Answers to Commonly asked "New Internet User" Questions

Status of this Memo

   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.

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.

New Questions and Answers

   In addition to updating information contained in the previous version
   of this FYI RFC, the following new questions have been added:

   Questions about Internet Organizations and Contacts:

     What is the InterNIC?

   Questions About Internet Services:

     What is gopher?
     What is the World Wide Web?  What is Mosaic?
     How do I find out about other Internet resource discovery tools?

 

 

 

 

 

User Services Working Group                                     [Page 1]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

Table of Contents

   1. Introduction.................................................  2
   2. Acknowledgements.............................................  2
   3. Questions About the Internet.................................  3
   4. Questions About TCP/IP.......................................  5
   5. Questions About the Domain Name System.......................  5
   6. Questions About Internet Documentation.......................  6
   7. Questions about Internet Organizations and Contacts.......... 13
   8. Questions About Services..................................... 18
   9. Mailing Lists and Sending Mail............................... 24
   10. Miscellaneous "Internet lore" questions..................... 26
   11. Suggested Reading........................................... 28
   12. References.................................................. 29
   13. Condensed Glossary.......................................... 31
   14. Security Considerations..................................... 44
   15. Authors' Addresses.......................................... 44

1. Introduction

   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.

   Future updates of this memo will be produced as User Services members
   become aware of additional questions that should be included, and of
   deficiencies or inaccuracies that should be amended in this document.
   Although the RFC number of this document will change with each
   update, it will always have the designation of FYI 4.  An additional
   FYI Q/A, FYI 7, is published that deals with intermediate and
   advanced Q/A topics [11].

2. Acknowledgements

   The following people deserve thanks for their help and contributions
   to this FYI Q/A: Matti Aarnio (FUNET), Susan Calcari (InterNIC),
   Corinne Carroll (BBN), Vint Cerf (MCI), Peter Deutsch (Bunyip), Alan
   Emtage (Bunyip), John Klensin (UNU), Thomas Lenggenhager (Switch),
   Doug Mildram (Xylogics), Tracy LaQuey Parker (Cisco), Craig Partridge
   (BBN), Jon Postel (ISI), Matt Power (MIT), Karen Roubicek (BBN),
   Patricia Smith (Merit), Gene Spafford (Purdue), and Carol Ward
   (Sterling Software/NASA NAIC).

 

 

 

User Services Working Group                                     [Page 2]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

3. Questions About the Internet

   3.1  What is the Internet?

      The Internet is a collection of thousands of networks linked by a
      common set of technical protocols which make it possible for users
      of any one of the networks to communicate with or use the services
      located on any of the other networks.  These protocols are
      referred to as TCP/IP or the TCP/IP protocol suite.  The Internet
      started with the ARPANET, but now includes such networks as the
      National Science Foundation Network (NSFNET), the Australian
      Academic and Research Network (AARNet), the NASA Science Internet
      (NSI), the Swiss Academic and Research Network (SWITCH), and about
      10,000 other large and small, commercial and research, networks.
      There are other major wide area networks that are not based on the
      TCP/IP protocols and are thus often not considered part of the
      Internet.  However, it is possible to communicate between them and
      the Internet via electronic mail because of mail gateways that act
      as "translators" between the different network protocols involved.

      Note: You will often see "internet" with a small "i".  This could
      refer to any network built based on TCP/IP, or might refer to
      networks using other protocol families that are composites built
      of smaller networks.

      See FYI 20 (RFC 1462), "FYI on 'What is the Internet?'" for a
      lengthier description of the Internet [13].

   3.2  I just got on the Internet.  What can I do now?

      You now have access to all the resources you are authorized to use
      on your own Internet host, on any other Internet host on which you
      have an account, and on any other Internet host that offers
      publicly accessible information.  The Internet gives you the
      ability to move information between these hosts via file
      transfers.  Once you are logged into one host, you can use the
      Internet to open a connection to another, login, and use its
      services interactively (this is known as remote login or
      "TELNETing").  In addition, you can send electronic mail to users
      at any Internet site and to users on many non-Internet sites that
      are accessible via electronic mail.

      There are various other services you can use.  For example, some
      hosts provide access to specialized databases or to archives of
      information.  The Internet Resource Guide provides information
      regarding some of these sites.  The Internet Resource Guide lists
      facilities on the Internet that are available to users.  Such
      facilities include supercomputer centers, library catalogs and

 

User Services Working Group                                     [Page 3]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

      specialized data collections.  The guide is maintained by the
      Directory Services portion of the InterNIC and is available online
      in a number of ways.  It is available for anonymous FTP from the
      host ds.internic.net in the resource-guide directory.  It is also
      readable via the InterNIC gopher (gopher internic.net).  For more
      information, contact admin@ds.internic.net or call the InterNIC at
      (800) 444-4345 or (908) 668-6587.

      Today the trend for Internet information services is to strive to
      present the users with a friendly interface to a variety of
      services.  The goal is to reduce the traditional needs for a user
      to know the source host of a service and the different command
      interfaces for different types of services.  The Internet Gopher
      (discussed more in the "Questions about Internet Services"
      section) is one such service to which you have access when you
      join the Internet.

   3.3  How do I find out if a site has a computer on the Internet?

      Frankly, it's almost impossible to find out if a site has a
      computer on the Internet by querying some Internet service itself.
      The most reliable way is to ask someone at the site you are
      interested in contacting.

      It is sometimes possible to find whether or not a site has been
      assigned an IP network number, which is a prerequisite for
      connecting an IP network to the Internet (which is only one type
      of Internet access).  To do so, query the WHOIS database,
      maintained by the Registration Services portion of the InterNIC.
      You have several options about how to do such a query.  The most
      common currently are to TELNET to the host rs.internic.net and
      invoke one of the search interfaces provided, or to run a WHOIS
      client locally on your machine and use it to make a query across
      the network.

      The RIPE Network Coordination Center (RIPE NCC) also maintains a
      large database of sites to whom they have assigned IP network
      numbers.  You can query it by TELNETing to info.ripe.net and
      stepping through the interactive interface they provide.

   3.4  How do I get a list of all the hosts on the Internet?

      You really don't want that.  The list includes more than 1.5
      million hosts.  Almost all of them require that you have access
      permission to actually use them.  You may really want to know
      which of these hosts provide services to the Internet community.
      Investigate using some of the network resource discovery tools,
      such as gopher, to gain easier access to Internet information.

 

User Services Working Group                                     [Page 4]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

4. Questions About TCP/IP

   4.1  What is TCP/IP?

      TCP/IP (Transmission Control Protocol/Internet Protocol) [4,5,6]
      is the common name for a family of over 100 data-communications
      protocols used to organize computers and data-communications
      equipment into computer networks.  TCP/IP was developed to
      interconnect hosts on ARPANET, PRNET (packet radio), and SATNET
      (packet satellite).  All three of these networks have since been
      retired; but TCP/IP lives on.  It is currently used on a large
      international network of networks called the Internet, whose
      members include universities, other research institutions,
      government facilities, and many corporations.  TCP/IP is also
      sometimes used for other networks, particularly local area
      networks that tie together numerous different kinds of computers
      or tie together engineering workstations.

   4.2  What are the other well-known standard protocols in the TCP/IP
        family?

      Other than TCP and IP, the three main protocols in the TCP/IP
      suite are the Simple Mail Transfer Protocol (SMTP) [8], the File
      Transfer Protocol (FTP) [3], and the TELNET Protocol [9].  There
      are many other protocols in use on the Internet.  The Internet
      Architecture Board (IAB) regularly publishes an RFC [2] that
      describes the state of standardization of the various Internet
      protocols.  This document is the best guide to the current status
      of Internet protocols and their recommended usage.

5.  Questions About the Domain Name System

   5.1  What is the Domain Name System?

      The Domain Name System (DNS) is a hierarchical, distributed method
      of organizing the name space of the Internet.  The DNS
      administratively groups hosts into a hierarchy of authority that
      allows addressing and other information to be widely distributed
      and maintained.  A big advantage to the DNS is that using it
      eliminates dependence on a centrally-maintained file that maps
      host names to addresses.

   5.2  What is a Fully Qualified Domain Name?

      A Fully Qualified Domain Name (FQDN) is a domain name that
      includes all higher level domains relevant to the entity named.
      If you think of the DNS as a tree-structure with each node having
      its own label, a Fully Qualified Domain Name for a specific node

 

User Services Working Group                                     [Page 5]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

      would be its label followed by the labels of all the other nodes
      between it and the root of the tree.  For example, for a host, a
      FQDN would include the string that identifies the particular host,
      plus all domains of which the host is a part up to and including
      the top-level domain (the root domain is always null).  For
      example, atlas.arc.nasa.gov is a Fully Qualified Domain Name for
      the host at 128.102.128.50.  In addition, arc.nasa.gov is the FQDN
      for the Ames Research Center (ARC) domain under nasa.gov.

6. Questions About Internet Documentation

   6.1  What is an RFC?

      The Request for Comments documents (RFCs) are working notes of the
      Internet research and development community.  A document in this
      series may be on essentially any topic related to computer
      communication, and may be anything from a meeting report to the
      specification of a standard.  Submissions for Requests for
      Comments may be sent to the RFC Editor (RFC-EDITOR@ISI.EDU).  The
      RFC Editor is Jon Postel.

      Most RFCs are the descriptions of network protocols or services,
      often giving detailed procedures and formats for their
      implementation.  Other RFCs report on the results of policy
      studies or summarize the work of technical committees or
      workshops.  All RFCs are considered public domain unless
      explicitly marked otherwise.

      While RFCs are not refereed publications, they do receive
      technical review from either the task forces, individual technical
      experts, or the RFC Editor, as appropriate.  Currently, most
      standards are published as RFCs, but not all RFCs specify
      standards.

      Anyone can submit a document for publication as an RFC.
      Submissions must be made via electronic mail to the RFC Editor.
      Please consult RFC 1543, "Instructions to RFC Authors" [10], for
      further information.  RFCs are accessible online in public access
      files, and a short message is sent to a notification distribution
      list indicating the availability of the memo.  Requests to be
      added to this distribution list should be sent to RFC-
      REQUEST@NIC.DDN.MIL.

      The online files are copied by interested people and printed or
      displayed at their sites on their equipment.  (An RFC may also be
      returned via electronic mail in response to an electronic mail
      query.) This means that the format of the online files must meet
      the constraints of a wide variety of printing and display

 

User Services Working Group                                     [Page 6]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

      equipment.

      Once a document is assigned an RFC number and published, that RFC
      is never revised or re-issued with the same number.  There is
      never a question of having the most recent version of a particular
      RFC.  However, a protocol (such as File Transfer Protocol (FTP))
      may be improved and re-documented many times in several different
      RFCs.  It is important to verify that you have the most recent RFC
      on a particular protocol.  The "Internet Official Protocol
      Standards" [2] memo is the reference for determining the correct
      RFC to refer to for the current specification of each protocol.

   6.2  How do I obtain RFCs?

      RFCs are available online at several repositories around the
      world.  For a list of repositories and instructions about how to
      obtain RFCs from each of the major U.S. ones, send a message to
      rfc-info@isi.edu.  As the text of the message, type
      "help: ways_to_get_rfcs" (without the quotes).

      An example of obtaining RFCs online follows.

      RFCs can be obtained via FTP from ds.internic.net with the
      pathname rfc/rfcNNNN.txt (where "NNNN" refers to the number of the
      RFC).  Login using FTP, username "anonymous" and your email
      address as password.  The Directory Services portion of the
      InterNIC also makes RFCs available via electronic mail, WAIS, and
      gopher.

      To obtain RFCs via electronic mail, send a mail message to
      mailserv@ds.internic.net and include any of the following commands
      in the message body:

         document-by-name rfcnnnn      where 'nnnn' is the RFC number
                                       The text version is sent.

         file /ftp/rfc/rfcnnnn.yyy     where 'nnnn' is the RFC number.
                                       and 'yyy' is 'txt' or 'ps'.

         help                          to get information on how to use
                                       the mailserver.

   6.3  How do I obtain a list of RFCs?

      Several sites make an index of RFCs available.  These sites are
      indicated in the ways_to_get_rfcs file mentioned above and in the
      next question.

 

User Services Working Group                                     [Page 7]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

   6.4  What is the RFC-INFO service?

      The Information Sciences Institute, University of Southern
      California (ISI) has a service called RFC-INFO.  Even though this
      is a service, rather than a document, we'll discuss it in this
      section because it is so closely tied to RFC information.

      RFC-INFO is an email based service to help in locating and
      retrieval of RFCs, FYIs, STDs, and IMRs.  Users can ask for
      "lists" of all RFCs and FYIs having certain attributes ("filters")
      such as their ID, keywords, title, author, issuing organization,
      and date.  Once an RFC is uniquely identified (e.g., by its RFC
      number) it may also be retrieved.

      To use the service, send email to: RFC-INFO@ISI.EDU with your
      requests as the text of the message.  Feel free to put anything in
      the SUBJECT, the system ignores it.  All input is case
      independent.  Report problems to: RFC-MANAGER@ISI.EDU.

      To get started, you may send a message to RFC-INFO@ISI.EDU with
      requests such as in the following examples (without the
      explanations between brackets):

      Help: Help              [to get this information]

      List: FYI               [list the FYI notes]
      List: RFC               [list RFCs with window as keyword or
                               in title]
        keywords: window
      List: FYI               [list FYIs about windows]
        Keywords: window
      List: *                 [list both RFCs and FYIs about windows]
        Keywords: window
      List: RFC               [list RFCs about ARPANET, ARPA NETWORK,
                               etc.]
        title: ARPA*NET
      List: RFC               [list RFCs issued by MITRE, dated
                               1989-1991]
        Organization: MITRE
        Dated-after:  Jan-01-1989
        Dated-before: Dec-31-1991
      List: RFC               [list RFCs obsoleting a given RFC]
        Obsoletes: RFC0010
      List: RFC               [list RFCs by authors starting with
                               "Bracken"]
        Author: Bracken*      [* is a wild card]
      List: RFC               [list RFCs by both Postel and Gillman]
        Authors: J. Postel    [note, the "filters" are ANDed]

 

User Services Working Group                                     [Page 8]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

        Authors: R. Gillman
      List: RFC               [list RFCs by any Crocker]
        Authors: Crocker
      List: RFC               [list only RFCs by S.D. Crocker]
        Authors: S.D. Crocker
      List: RFC               [list only RFCs by D. Crocker]
        Authors: D. Crocker

      Retrieve: RFC           [retrieve RFC-822]
        Doc-ID: RFC0822       [note, always 4 digits in RFC#]

      Help: Manual            [to retrieve the long user manual,
                               30+ pages]
      Help: List              [how to use the LIST request]
      Help: Retrieve          [how to use the RETRIEVE request]
      Help: Topics            [list topics for which help is available]
      Help: Dates             ["Dates" is such a topic]
      List: keywords          [list the keywords in use]
      List: organizations     [list the organizations known to the
                               system]

   6.5  Which RFCs are Standards?

      See "Internet Official Protocol Standards" (currently RFC 1540)
      [2].  This RFC documents the status of each RFC on the Internet
      standards track, as well as the status of RFCs of other types.  It
      is updated periodically; make sure you are referring to the most
      recent version.  In addition, the RFC Index maintained at the
      ds.internic.net repository notes the status of each RFC listed.

   6.6  What is an FYI?

      FYI stands for For Your Information.  FYIs are a subset of the RFC
      series of online documents.

      FYI 1 states, "The FYI series of notes is designed to provide
      Internet users with a central repository of information about any
      topics which relate to the Internet.  FYI topics may range from
      historical memos on 'Why it was was done this way' to answers to
      commonly asked operational questions.  The FYIs are intended for a
      wide audience.  Some FYIs will cater to beginners, while others
      will discuss more advanced topics."

      In general, then, FYI documents tend to be more information
      oriented, while RFCs are usually (but not always) more technically
      oriented.

      FYI documents are assigned both an FYI number and an RFC number.

 

User Services Working Group                                     [Page 9]

RFC 1594            FYI Q/A - for New Internet Users          March 1994

      As RFCs, if an FYI is ever updated, it is issued again with a new
      RFC number; however, its FYI number remains unchanged.  This can
      be a little confusing at first, but the aim is to help users
      identify which FYIs are about which topics.  For example, FYI 4
      will always be FYI 4, even though it may be updated several times
      and during that process receive different RFC numbers.  Thus, you
      need only to remember the FYI number to find the proper document.
      Of course, remembering titles often works as well.

      FYIs can be obtained in the same way RFCs can and from the same
      repositories.  In general, their pathnames are fyi/fyiNN.txt or
      fyi/fyiNN.ps, where NN is the number of the FYI without leading
      zeroes.

   6.7  What is an STD?

      The newest subseries of RFCs are the STDs (Standards).  RFC 1311
      [12], which introduces this subseries, states that the intent of
      STDs is to identify clearly those RFCs that document Internet
      standards.  An STD number will be assigned only to those
      specifications that have completed the full process of
      standardization in the Internet.  Existing Internet standards have
      been assigned STD numbers; a list of them can be found both in RFC
      1311 and in the, "Internet Official Protocol Standards" RFC.

      Like FYIs, once a standard has been assigned an STD number, that
      number will not change, even if the standard is reworked and re-
      specified and later issued with a new RFC number.

      It is important to differentiate between a "standard" and
      "document".  Different RFC documents will always have different
      RFC numbers.  However, sometimes the complete specification for a
      standard will be contained in more than one RFC document.  When
      this happens, each of the RFC documents that is part of the
      specification for that standard will carry the same STD number.
      For example, the Domain Name System (DNS) is specified by the
      combination of RFC 1034 and RFC 1035; therefore, both of those
      RFCs are labeled STD 13.

   6.8  What is the Internet Monthly Report?

      The Internet Monthly Report (IMR) communicates online to the
      Internet community the accomplishments, milestones reached, or
      problems discovered by the participating organizations.  Many
      organizations involved in the Internet provide monthly updates of
      their activities for inclusion in this report.  The IMR is for
      Internet information purposes only.

 

ادامه مطلب

Network Working Group                                          K. Bowers
Request for Comments: 1175                                          CNRI
FYI: 3                                                         T. LaQuey
                                                                 U Texas
                                                             J. Reynolds
                                                                     ISI
                                                             K. Roubicek
                                                                   BBNST
                                                                M. Stahl
                                                                     SRI
                                                                 A. Yuan
                                                                   MITRE
                                                             August 1990

                        FYI on Where to Start -
             A Bibliography of Internetworking Information

Status of this Memo

   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.  Distribution of this memo is unlimited.

Abstract

   The intent of this bibliography is to offer a representative
   collection of resources of information that will help the reader
   become familiar with the concepts of internetworking.  It is meant to
   be a starting place for further research.  There are references to
   other sources of information for those users wishing to pursue, in
   greater depth, the issues and complexities of the current networking
   environment.

 

 

 

 

 

 

 

User Documents Working Group                                    [Page i]

RFC 1175                   FYI - Bibliography                August 1990

 

 

                           Table of Contents

 

   INTRODUCTION ...................................................    2

   Background and Purpose .........................................    2

   Scope ..........................................................    2

   Organization of Document .......................................    2

   Obtaining Files By Anonymous FTP ...............................    3

   Submitting Entries to the Bibliography .........................    4

   ARTICLES .......................................................    6

      BIBLIOGRAPHIES ..............................................    9

      BOOKS .......................................................   11

      CONFERENCES AND WORKSHOPS ...................................   16

      GLOSSARIES ..................................................   18

      GUIDES ......................................................   19

      MULTIMEDIA ..................................................   23

      NEWSLETTERS .................................................   24

      REPORTS AND PAPERS ..........................................   27

      REQUEST FOR COMMENTS (RFC) ..................................   31

      The Request for Comments Document Series ....................   31

   Key Basic Beige RFC Abstracts ..................................   32

      APPENDIX A ..................................................   39

      APPENDIX B ..................................................   40

 

User Documents Working Group                                    [Page 1]

RFC 1175                   FYI - Bibliography                August 1990

1.  Introduction

1a. Background and Purpose

   On 1 June 1989, several members of the IETF User Services Working
   Group convened an interim working group session at the JVNC
   Supercomputer Center in Princeton, NJ.  The purpose of the meeting
   was to form a distinct working group that would assemble a
   bibliography of useful information about the Internet for end users
   and for those who help end users.  The first official meeting of the
   User Documents Working Group was held at the Stanford IETF in July
   1989.  The goal of the working group was to prepare a bibliography of
   on-line and hard copy documents, reference materials, and multimedia
   training tools that address general networking information and "how
   to use the Internet".  The target audience was beginner level and
   intermediate level end users.

1b. Scope

   This bibliography is the result of volunteer work provided by members
   of the User Documents Working Group.  The intent of this effort is to
   present a representative collection of materials that will help the
   reader become familiar with the concepts of internetworking and will
   form the basis for future study.  This is, quite simply, a good place
   to start.  References to other sources of information within this
   collection of materials will be useful to readers who wish to pursue,
   in greater depth, the issues and complexities of the current
   networking environment.  Please send comments to us-wg@nnsc.nsf.net.

1c. Organization of Document

   This version of the bibliography is divided into 10 distinct
   categories of material, and each category is presented in a separate
   section:

           2  ARTICLES
           3  BIBLIOGRAPHIES
           4  BOOKS
           5  CONFERENCES AND WORKSHOPS
           6  GLOSSARIES
           7  GUIDES
           8  MULTIMEDIA
           9  NEWSLETTERS
           10 REPORTS AND PAPERS
           11 REQUESTS FOR COMMENTS (RFCs)

   Within each section, material is arranged in alphabetical order by
   author or authoring organization with the exception of Section 11:

ادامه مطلب

Network Working Group                                           R. Enger
Request for Comments: 1470                                           ANS
FYI: 2                                                       J. Reynolds
Obsoletes: 1147                                                      ISI
                                                                 Editors
                                                               June 1993

               FYI on a Network Management Tool Catalog:
          Tools for Monitoring and Debugging TCP/IP Internets
                       and Interconnected Devices

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   The goal of this FYI memo is to provide an update to FYI 2, RFC 1147
   [1], which provided practical information to site administrators and
   network managers.  New and/or updated tools are listed in this RFC.
   Additonal descriptions are welcome, and should be sent to: noctools-
   entries@merit.edu.

Introduction

   A static document cannot incorporate references to the latest tools
   nor recent revisions to the older catalog entries.  To provide a more
   timely and responsive information source, the NOCtools catalog is
   available on-line via the Internet and Usenet.

      news    comp.networks.noctools
      ftp     wuarchive.wustl.edu:/doc/noctools

   Because of publication delays and other factors, some of the entries
   in this catalog may be out of date.  The reader is urged to consult
   the on-line service to obtain the most up-to-date information.

   The index provided in this document reflects the current contents of
   the on-line documentation.

   The NOCtools2 Working Group of the Internet Engineering Task Force
   (IETF) has compiled this revised catalog.  Future revisions will be
   incorporated into the on-line NOCtools catalog.  The reader is
   encouraged to submit new or revised entries for (near-immediate)
   electronic publication.

 

NOCTools2 Working Group                                         [Page 1]

RFC 1470          FYI: Network Management Tool Catalog         June 1993

   The tools described in this catalog are in no way endorsed by the
   IETF.  For the most part, we have neither evaluated the tools in this
   catalog, nor validated their descriptions.  Most of the descriptions
   of commercial tools have been provided by vendors.  Caveat Emptor.

Acknowledgements

   This catalog is the result of work on the part of the NOCTools2
   Working Group of the User Services Area of the IETF.  The following
   individuals made especially notable contributions: Chris Myers,
   Darren Kinley, Gary Malkin, Mohamed Ellozy, and Mike Patton.

Current Postings

   The current contents of the NOCtools catalog may be retrieved via
   anonymous FTP from wuarchive.wustl.edu.  The entries are stored as
   individual files in the directory /doc/noctools.

"No-Writeups" Appendix

   This section contains references to tools which are known to exist,
   but which have not been fully cataloged.  If anyone wishes to author
   an entry for one of these tools please contact us at:

        noctools-request@merit.edu

   Keep in mind that if these or other tools are included in the future,
   they will be available in the on-line version of the catalog.

   Each mention is separated by a for improved readability.
   If you intend to actually print-out this section of the catalog, then
   you should probably strip-out the .

How to Submit/Update an Entry

      1) review the template included below to determine what
         information you will need to collect,
      2) review the keywords to see what your indexing options are,
      3) assemble (update) catalog entry to include results of
         1) and 2).
      4) Submit your entry using either of the following two methods:

         a) Post your submission to: comp.internet.noctools.submissions
         b) Email your submission to: noctools-entries@merit.edu

   New entries will be circulated automatically upon reception.  As time
   permits, the NOCtools editors will review recent submissions and
   incorporate them into the master indexes.  Enquiries regarding the

 

NOCTools2 Working Group                                         [Page 2]

RFC 1470          FYI: Network Management Tool Catalog         June 1993

   status of a submission should be E-Mailed to:

                        noctools-request@merit.edu

   Those submitting an entry to the catalog should insure that any E-
   mail addresses provided are correct and functional.  Either the
   catalog editors or prospective users of your tool may wish to reach
   you.

ادامه مطلب

Network Working Group                                          G. Malkin
Request for Comments: 1150                                       Proteon
FYI: 1                                                       J. Reynolds
                                                                     ISI
                                                              March 1990

                            F.Y.I. on F.Y.I.

                    Introduction to the F.Y.I. Notes

Status of this Memo

   This RFC 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.  Distribution of this
   memo is unlimited.

1.  Introduction

   The FYI series of notes is designed to provide Internet users with a
   central repository of information about any topics which relate to
   the Internet.  FYIs topics may range from historical memos on "Why it
   was was done this way" to answers to commonly asked operational
   questions.

   The FYIs are intended for a wide audience.  Some FYIs will cater to
   beginners, while others will discuss more advanced topics.  An FYI
   may be submitted by anyone who has something to contribute and has
   the time to do so.

2.  Why RFCs

   There are several reasons why the FYIs are part of the larger RFC
   series of notes.  The formost reason is that the distribution
   mechanisms for RFCs are tried and true.  Anyone who can get an RFC,
   can automatically get an FYI.  More importantly, anyone who knows of
   the RFC series, can easily find out about the FYIs.

   Another reason for making FYIs part of the RFC series is that the
   maintainance mechanisms for RFCs are already in place and funded.  It
   makes sense to maintain similar documents is a similar way.  After
   all, there have been informational RFCs before.

   Finally, the name RFC has come to carry a meaning with it.  There is
   credibility associated memos carrying the RFC label.  FYIs should
   share that respect.

 

Malkin & Reynolds                                               [Page 1]

RFC 1150                    F.Y.I. on F.Y.I.                  March 1990

3.  Format Rules

   Since the FYIs are a part of the RFC series, they must conform to
   RFC-1111 (Request for Comments on Request for Comments: Instructions
   to RFC Authors) with respect to format.  Ideally, they should be
   submitted in ASCII format, as described by section 2a, of RFC-1111.

4.  Status Statement

   Each RFC must include on its first page the "Status of this Memo"
   section which contains a paragraph describing the intention of the
   RFC.  This section is meant to convey the status granted by the RFC
   Editor and the Internet Activities Board (IAB).  There are several
   reasons for publishing a memo as an RFC, for example, to make
   available some information for interested people, or to begin or
   continue a discussion of an interesting idea, or to make available
   the specification of a protocol.

   For example:

   This RFC 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.  Distribution of this
   memo is unlimited.

5.  Distribution Statement

   Each FYI is to also include a "distribution statement".  As the
   purpose of the FYI series is to disseminate information, there is no
   reason for the distribution to be anything other than "unlimited".

   Typically, the distribution statement will simply be the sentence
   "Distribution of this memo is unlimited." appended to the "Status of
   this Memo" section.

6. Security Considerations

   All FYIs must contain a section that discusses the security
   considerations of the procedures that are the main topic of the RFC.

7.  Author's Address

   Each FYI must have at the very end a section giving the author's
   address, including the name and postal address, the telephone number,
   and the Internet email address.

 

 

Malkin & Reynolds                                               [Page 2]

RFC 1150                    F.Y.I. on F.Y.I.                  March 1990

8.  Relation to other FYIs

   Sometimes an FYI adds information on a topic discussed in a previous
   FYI or completely replaces an earlier FYI.  There are two terms used
   for these cases respectively, UPDATES and OBSOLETES.  A document that
   obsoletes an earlier document can stand on its own.  A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the existing
   document, and has limited usefulness independently.

   UPDATES

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

   OBSOLETES

      To be used to refer to an earlier document that is replaced by
      this document.  This document contains either revised information,
      or else all of the same information plus some new information,
      however extensive or brief that new information is; i.e., this
      document can be used alone, without reference to the older
      document.

   OBSOLETED-BY

      To be used to refer to the newer document that replaces the older
      document.

   UPDATED-BY

      To be used to refer to the newer document that adds information to
      the existing, still useful, document.

9. The FYI Editors

   All FYIs are submitted to the IETF User Services Working Group for
   review prior to their submission to the RFC Editor.

   Submissions may be made to:

 

 

 

Malkin & Reynolds                                               [Page 3]

RFC 1150                    F.Y.I. on F.Y.I.                  March 1990

         Joyce K. Reynolds
         Chair, User Services Working Group
         USC - Information Sciences Institute
         4676 Admiralty Way
         Marina del Rey, California  90292-6695

         Phone: (213) 822-1511

         Electronic mail: JKREY@ISI.EDU

10.  The FYI Announcement List

   New FYIs are announced to the RFC distribution list maintained by the
   SRI Network Information Center (NIC).  Contact the SRI-NIC to be
   added or deleted from this mailing list by sending an email message
   to RFC-REQUEST@NIC.DDN.MIL.

11.  Obtaining FYIs

   FYIs can be obtained via FTP from NIC.DDN.MIL, with the pathname
   FYI:mm.TXT, or RFC:RFCnnnn.TXT (where "mm" refers to the number of
   the FYI and "nnnn" refers to the number of the RFC).  Login with FTP,
   username ANONYMOUS and password GUEST.  The NIC also provides an
   automatic mail service for those sites which cannot use FTP.  Address
   the request to SERVICE@NIC.DDN.MIL and in the subject field of the
   message indicate the FYI or RFC number, as in "Subject: FYI mm" or
   "Subject: RFC nnnn".

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Gary Scott Malkin
   Proteon, Inc.
   2 Technology Drive
   Westborough, MA  01581-5008
   Phone:  (508) 898-2800
   EMail:  gmalkin@proteon.com

   Joyce K. Reynolds
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292-6695
   Phone:  (213) 822-1511
   EMail:  jkrey@isi.edu