archive-gr.com » GR » T » TEIPIR.GR

Total: 878

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • "Multimedia Educational Software" Task Force: Call For Expression of Interest
    demonstration concerning multimedia applications and presenting a particular interest at European level in the fields of education and training whatever their content may be history music geography mathematics etc or the section of the public for whom it is intended general public teachers training centres enterprises 1 8 RDD Activities on the integration of multimedia educational software in education and training whether destined for individual or group use For example in specific professional contexts such as tele working and tele placement or for specific section of the public such as handicapped people 1 9 RDD Activities on the current learning environments in which multimedia software is used for education and training 1 10 RDD Activities on learning methods enabled by the use of multimedia tools and on the pedagogical methods which are most appropriate for different user profiles 1 11 Activities aiming to examine the process dimension of education from the point of view of quality and standards 1 12 Other RDD Activities II Support for the creation and production of multimedia educational software 2 1 Support of the creation of training modules intended for the designers of multimedia education software 2 2 Support for European cooperation between those who have content available for use in multimedia creators producers editors and users in the areas of design production and cultural adaptation language used content 2 3 Other support activities III Stimulating the use of multimedia educational software 3 1 Stimulating the use of educational software which schools colleges universities or training centres could exchange at European level either by telematic networks or other methods 3 2 Integrating multimedia educational software into different European training and education systems by level subjects and professional activities concerned 3 3 Quality issues in the delivery of Education and Training using multimedia software 3 4 Other stimulation activities IV Awareness raising and diffusion 4 1 Improve at European level information on and evaluation of products and services available quality and possibilities for use 4 2 Encourage cooperation and experience exchange between European user organizations 4 3 Improvement of initial and continuous training of teachers and trainers in the manipulation and use of multimedia tools for pedagogical purposes 4 4 Facilitate access by various categories of users to multimedia educational software whether this is by telematic networks or on a local basis 4 5 Other awareness raising activities V Other Activities ANNEX I MULTIMEDIA EDUCATIONAL SOFTWARE CALL FOR EXPRESSION OF INTEREST Announcement published in the Official Journal of the European Union issued June 15th 1995 The Commission recently set up a Multimedia Educational Software Task Force whose job is to identify joint projects of industrial interest which will mobilize the relevant partners in the Member States Funding will be available from European programmes which have already been adopted such as the 4th framework programme of research and technological development Telematic Applications Information Technologies Targeted Socio economic Research and the education and training programmes Socrates Leonardo da Vinci and from programmes currently being adopted Media 2 INFO

    Original URL path: http://web.teipir.gr/new/eok/appint.html (2016-02-14)
    Open archived version from archive


  • SPOYSASTES
    ¼íïìá ÌáõñïìÜôçò Ãåþñãéïò Çëéêßá 22 åôþí ÓðïõäáóôÞò ôïõ ôìÞìáôïò Çëåêôñïíéêþí Õðïëïãéóôéêþí Óõóôçìáôþí ôïõ ÔÅÉ ÐÅÉÑÁÉÁ ¼íïìá ÌðáóäÝêçò ÓôÝñãéïò Çëéêßá 22 åôþí ÓðïõäáóôÞò ôïõ ôìÞìáôïò Çëåêôñïíéêþí Õðïëïãéóôéêþí Óõóôçìáôþí ôïõ ÔÅÉ ÐÅÉÑÁÉÁ

    Original URL path: http://web.teipir.gr/AgiaLavra/hotdog25/data/geost.htm (2016-02-14)
    Open archived version from archive

  • AGIA LAYRA - TEI PEIRAIA
    Ýãéíå ôï 961 Ëåéôïõñãßåò ãßíïíôáé êÜèå ÄåõôÝñá ôïõ ÐÜó á êáé ôùí Åéóüäùí ôçò Èåïôüêïõ Éóôïñéêüò Íáüò Åéêüíåò áðü ôï íáü ôçò åðáíáóôÜóåùò æùíôáíåýïíôáò ôéò ìíÞìåò ôçò åíÜñîåùò ôïõ ìåãÜëïõ áãþíá Ï íáüò åßíáé Ýíá ëéèüêôéóôï ôñßêïã ï êôßóìá áãéïñßôéêïõ ôýðïõ óå áðëïýóôåñç ìïñöÞ Çìåñïìåíßá åíÜñîåùò ôïõ Éóôïñéêïý íáïý ç 19 Ìáñôßïõ 1689 Êáèïëéêüò Íáüò Åéêüíåò áðü ôçí åîùôåñéêÞ êáé åóùôåñéêÞ Üðïøç ôïõ Êáèïëéêïý ôçò óçìåñéíÞò ÌïíÞò ÉóôïñéêÜ ÊåéìÞëéá Ç

    Original URL path: http://web.teipir.gr/AgiaLavra/hotdog25/data/agla2.htm (2016-02-14)
    Open archived version from archive

  • CoOl Cd'S...
    CD of the DAY HOT Mix nbsp nbsp Click here nbsp and good luck Go Back

    Original URL path: http://web.teipir.gr/HOTcd/html/cd1.hotmix.html (2016-02-14)
    Open archived version from archive

  • CoOl Cd'S...
    CoOl Cd S CD of the DAY JAVA SIG nbsp nbsp Click Here nbsp and good luck Go Back

    Original URL path: http://web.teipir.gr/HOTcd/html/cd2.java.html (2016-02-14)
    Open archived version from archive


  • the operations of the gateways 11 DARPA Internet Gateway September 1982 RFC 823 4 PROTOCOLS SUPPORTED BY THE GATEWAY A number of protocols are supported by the gateway to provide dynamic routing monitoring debugging and error reporting These protocols are described below 4 1 Cross Net Debugging Protocol The Cross Net Debugging Protocol XNET 8 is used to load the gateway and to examine and deposit data The gateway supports the following XNET op codes o NOP o Debug o End Debug o Deposit o Examine o Create Process 4 2 Host Monitoring Protocol The Host Monitoring Protocol HMP 6 is used to collect measurements and status information from the gateways Exceptional conditions in the gateways are reported in HMP traps The status of a gateway s interfaces neighbors and the networks which it can reach are reported in the HMP status message 12 DARPA Internet Gateway September 1982 RFC 823 Two types of gateway statistics the Host Traffic Matrix and the gateway throughput are currently defined by the HMP The Host Traffic Matrix records the number of datagrams that pass through the gateway with a given IP source destination and protocol number The gateway throughput message collects a number of important counters that are kept by the gateway The current gateway reports the following values o Datagrams dropped because destination net unreachable o Datagrams dropped because destination host unreachable o Per Interface Datagrams received with IP errors Datagrams received for this gateway Datagrams received to be forwarded Datagrams looped Bytes received Datagrams sent originating at this gateway Datagrams sent to destination hosts Datagrams dropped due to flow control limitations Datagrams dropped due to full queue Bytes sent o Per Neighbor Routing updates sent to Routing updates received from Datagrams sent originating here Datagrams forwarded to Datagrams dropped due to flow control limitations Datagrams dropped due to full queue Bytes sent 13 DARPA Internet Gateway September 1982 RFC 823 4 3 ICMP The gateway will generate the following ICMP messages under appropriate circumstances as defined by the ICMP specification 4 o Echo Reply o Destination Unreachable o Source Quench o Redirect o Time Exceeded o Parameter Problem o Information Reply 4 4 Gateway to Gateway Protocol The gateway uses the Gateway to Gateway Protocol GGP to determine connectivity to networks and neighbor gateways it is also used in the implementation of a dynamic shortest path routing algorithm The current GGP message formats for release 1003 of the gateway software are presented in Appendix A 4 4 1 Determining Connectivity to Networks When a gateway starts running it assumes that all its neighbor gateways are down that it is disconnected from 14 DARPA Internet Gateway September 1982 RFC 823 networks to which it is attached and that the distance reported in routing updates from each neighbor to each network is infinity The gateway first determines the state of its connectivity to networks to which it is physically attached The gateway s connection to a network is declared up if it can send and receive internet datagrams on its interface to that network Note that the method that the gateway uses to determine its connectivity to a network is network dependent In some networks the host to network protocol determines whether or not datagrams can be sent and received on the host interface In these networks the gateway simply checks status information provided by the protocol in order to determine if it can communicate with the network In other networks where the host to network protocols are less sophisticated it may be necessary for the gateway to send datagrams to itself to determine if it can communicate with the network In these networks the gateways periodically poll the network using GGP network interface status messages Appendix A to determine if the network interface is operational The gateway has two rules relevant to computing distances to networks 1 if the gateway can send and receive traffic on its 15 DARPA Internet Gateway September 1982 RFC 823 network interface its distance to the network is zero 2 if it cannot send and receive traffic on the interface its distance to the network is infinity Note that if a gateway s network interface is not working it may still be able to send traffic to the network on an alternate route via one of its neighbor gateways 4 4 2 Determining Connectivity to Neighbors The gateway determines connectivity to neighbors using a K out of N algorithm Every 15 seconds the gateway sends GGP Echo messages Appendix A to each of its neighbors The neighbors respond by sending GGP echo replies If there is no reply to K out of N current values are K 3 and N 4 echo messages sent to a neighbor the neighbor is declared down If a neighbor is down and J out of M current values are J 2 and M 4 echo replies are received the neighbor is declared to be up The values of J K M N and the time interval are operational parameters which can be adjusted as required 16 DARPA Internet Gateway September 1982 RFC 823 4 4 3 Exchanging Routing Information The gateway sends routing information in GGP Routing Update messages The gateway receives and transmits routing information reliably using sequence numbered messages and a retransmission and acknowledgment scheme as explained below For each neighbor the gateway remembers the Receive Sequence Number R that it received in the most recent routing update from that neighbor This value is initialized with the sequence number in the first Routing Update received from a neighbor after that neighbor s status is set to up On receipt of a routing update from a neighbor the gateway subtracts the Receive Sequence Number R from the sequence number in the routing update S If this value S R is greater than or equal to zero then the gateway accepts the routing update sends an acknowledgment see Appendix A to the neighbor containing the sequence number S and replaces the Receive Sequence Number R with S If this value S R is less than zero the gateway rejects the routing update and sends a negative acknowledgment Appendix A to the neighbor with sequence number R The gateway has a Send Sequence Number N for sending routing updates to all of its neighbors This sequence number 17 DARPA Internet Gateway September 1982 RFC 823 can be initialized to any value The Send Sequence Number is incremented each time a new routing update is created On receiving an acknowledgment for a routing update the gateway subtracts the sequence number acknowledged A from the Send Sequence Number N If the value N A is non zero then an old routing update is being acknowledged The gateway continues to retransmit the most recent routing update to the neighbor that sent the acknowledgment If N A is zero the routing update has been acknowledged Note that only the most recent routing update must be acknowledged if a second routing update is generated before the first routing update is acknowledged only the second routing update must be acknowledged If a negative acknowledgment is received the gateway subtracts the sequence number negatively acknowledged A from its Send Sequence Number N If this value N A is less than zero then the gateway replaces its Send Sequence Number N with the sequence number negatively acknowledged plus one A 1 and retransmits the routing update to all of its neighbors If N A is greater than or equal to zero then the gateway continues to retransmit the routing update using sequence number N In order to maintain the correct sequence numbers at all gateways routing updates must be retransmitted to all neighbors if the Send 18 DARPA Internet Gateway September 1982 RFC 823 Sequence Number changes even if the routing information does not change The gateway retransmits routing updates periodically until they are acknowledged and whenever its Send Sequence Number changes The gateway sends routing updates only to neighbors that are in the up state 4 4 4 Computing Routes A routing update contains a list of networks that are reachable through this gateway and the distance in number of hops to each network mentioned The routing update only contains information about a network if the gateway believes that it is as close or closer to that network then the neighbor which is to receive the routing update The network address may be an internet class A B or C address The information inside a routing update is processed as follows The gateway contains an N x K distance matrix where N is the number of networks and K is the number of neighbor gateways An entry in this matrix represented as dm I J is the distance to network I from neighbor J as reported in the most 19 DARPA Internet Gateway September 1982 RFC 823 recent routing update from neighbor J The gateway also contains a vector indicating the connectivity between itself and its neighbor gateways The values in this vector are computed as discussed above see Section 4 4 2 Determining Connectivity to Neighbors The value of the Jth entry of this vector which is the connectivity between the gateway and the Jth neighbor is represented as d J The gateway copies the routing update received from the Jth neighbor into the appropriate row of the distance matrix then updates its routes as follows The gateway calculates a minimum distance vector which contains the minimum distance to each network from the gateway The Ith entry of this vector represented as MinD I is MinD I minimum over all neighbors of d J dm I J where d J is the distance between the gateway and the Jth neighbor and dm I J is the distance from the Jth neighbor to the Ith network If the Ith network is attached to the gateway and the gateway can send and receive traffic on its network interface see Section 4 4 2 then the gateway sets the Ith entry of the minimum distance vector to zero 20 DARPA Internet Gateway September 1982 RFC 823 Using the minimum distance vector the gateway computes a list of neighbor gateways through which to send traffic to each network The entry for a given network contains one of the neighbors that is the minimum distance away from that network After updating its routes to the networks the gateway computes the new routing updates to be sent to its neighbors The gateway reports a network to a neighbor only if it is as close to or closer to that network than its neighbor For each network I the routing update contains the address of the network and the minimum distance to that network which is MinD I Finally the gateway must determine whether it should send routing updates to its neighbors The gateway sends new updates to its neighbors if every one of the following three conditions occurs 1 one of the gateway s interfaces changes state 2 one of the gateway s neighbor gateways changes state and 3 the gateway receives a routing update from a neighbor that is different from the update that it had previously received from that neighbor The gateway sends routing updates only to neighbors that are currently in the up state The gateway requests a routing update from neighbors that are in the up state but from which it has yet received a 21 DARPA Internet Gateway September 1982 RFC 823 routing update Routing updates are requested by setting the appropriate bit in the routing update being sent Appendix A Similarly if a gateway receives from a neighbor a routing update in which the bit requesting a routing update is set the gateway sends the neighbor the most recent routing update 4 4 5 Non Routing Gateways A Non routing Gateway is a gateway that forwards internet traffic but does not implement the GGP routing algorithm Networks that are behind a Non routing Gateway are known a priori to Routing Gateways There can be one or more of these networks which are considered to be directly connected to the Non routing Gateway A Routing Gateway will forward a datagram to a Non routing Gateway if it is addressed to a network behind the Non routing Gateway Routing Gateways currently do not send Redirects for Non routing Gateways A Routing Gateway will always use another Routing Gateway as a path instead of a Non routing Gateways if both exist and are the same number of hops away from the destination network The Non routing Gateways path will be used only when the Routing Gateway path is down when the Routing Gateway path comes back up it will be used again 22 DARPA Internet Gateway September 1982 RFC 823 4 4 6 Adding New Neighbors and Networks Gateways dynamically add routing information about new neighbors and new networks to their tables The gateway maintains a list of neighbor gateway addresses When a routing update is received the gateway searches this list of addresses for the Internet source address of the routing update message If the Internet source address of the routing update is not contained in the list of neighbor addresses the gateway adds this address to the list of neighbor addresses and sets the neighbor s connectivity status to down Routing updates are not accepted from neighbors until the GGP polling mechanism has determined that the neighbor is up This strategy of adding new neighbors requires that one gateway in each pair of neighbor gateways must have the neighbor s address configured in its tables The newest gateway can be given a complete list of neighbors thus avoiding the need to re configure older gateways when new gateways are installed Gateways obtain routing information about new networks in several steps The gateway has a list of all the networks for which it currently maintains routing information When a routing update is received if the routing update contains information 23 DARPA Internet Gateway September 1982 RFC 823 about a new network the gateway adds this network to the list of networks for which it maintains routing information Next the gateway adds the new network to its distance matrix The distance matrix comprises the is the matrix of distances number of hops to networks as reported in routing updates from the neighbor gateways The gateway sets the distance to all new networks to infinity and then computes new routes and new routing updates as outlined above 4 5 Exterior Gateway Protocol The Exterior Gateway Protocol EGP is used to permit other gateways and gateway systems to pass routing information to the DARPA Internet gateways The use of the EGP permits the user to perceive all of the networks and gateways as part of one total Internet system even though the exterior gateways are disjoint and may use a routing algorithm that is different and not compatible with that used in the interior gateways The important elements of the EGP are o Neighbor Acquisition The procedure by which a gateway requests that it become a neighbor of another gateway This is used when a gateway wants to become a neighbor of another in order to pass 24 DARPA Internet Gateway September 1982 RFC 823 routing information This includes the capability to accept or refuse the request o Neighbor Up Down The procedure by which a gateway decides if another gateway is up or down o Network Reachability Information The facility used to pass routing and neighbor information between gateways o Gateway Going Down The ability of a gateway to inform other gateways that it is going down and no longer has any routes to any other networks This permits a gateway to go down in an orderly way without disrupting the rest of the Internet system A complete description of the EGP can be found in IEN 209 the Exterior Gateway Protocol 10 25 DARPA Internet Gateway September 1982 RFC 823 5 GATEWAY SOFTWARE The DARPA Internet Gateway runs under the MOS operating system 9 which provides facilities for o Multiple processes o Interprocess communication o Buffer management o Asynchronous input output o Shareable real time clock There is a MOS process for each network that the gateway is directly connected to A data structure called a NETBLOCK contains variables of interest for each network and pointers to local network routines Network processes run common gateway code while network specific functions are dispatched to the routines pointed to in the NETBLOCK There are also processes for gateway functions which require their own timing such as GGP and HMP 5 1 Software Structure The gateway software can be divided conceptually into three parts MOS Device Drivers Network software and Shared Gateway software 26 DARPA Internet Gateway September 1982 RFC 823 5 1 1 Device Drivers The gateway has a set of routines to handle sending and receiving data for each type of hardware interface There are routines for initialization initiation and interruption for both the transmit and receive sides of a device The gateway supports the following types of devices a ACC LSI 11 1822 b DEC IMP11a 1822 c ACC LHDH 1822 d ACC VDH11E e ACC VDH11C f Proteon Ring Network g RSRE HDLC h Interlan Ethernet i BBN Fibernet j ACC XQ CP X 25 k ACC XQ CP HDH 5 1 2 Network Software For each connected network the gateway has a set of eight routines which handle local network functions The network routines and their functions are described briefly below Planned not yet supported 27 DARPA Internet Gateway September 1982 RFC 823 Up net Perform local network initialization such as flapping the 1822 ready line Sg net Handle specific local network timing functions such as timing out 1822 Destination Deads Rc net A message has been received from the network interface Check for any input errors Wc net A message has been transmitted to the network interface Check for any output errors Rs net Set up a buffer

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0823.txt (2016-02-14)
    Open archived version from archive


  • name are read left to right from the most specific lowest to the least specific highest Internally programs that manipulate domain names represent them as sequences of labels where each label is a length octet followed by an octet string Because all domain names end at the root which has a null string for a label these internal Mockapetris Page 6 RFC 882 November 1983 Domain Names Concepts and Facilities representations can use a length byte of zero to terminate a domain name When domain names are printed labels in a path are separated by dots The root label and its associated dot are omitted from printed domain names but the root can be named by a null domain name in this memo To simplify implementations the total number of octets that represent label octets and label lengths is limited to 255 Thus a printed domain name can be up to 254 characters A special label is defined that matches any other label This label is the asterisk or An asterisk matches a single label Thus ARPA matches FOO ARPA but does not match FOO BAR ARPA The asterisk is mainly used to create default resource records at the boundary between protocol families and requires prudence in its use A domain is identified by a domain name and consists of that part of the domain name space that is at or below the domain name which specifies the domain A domain is a subdomain of another domain if it is contained within that domain This relationship can be tested by seeing if the subdomain s name has the containing domain s name as the right part of its name For example A B C D is a subdomain of B C D C D D and This tree structure is intended to parallel the administrative organization and delegation of authority Potentially each node or leaf on the tree can create new subdomains ad infinitum In practice this delegation can be limited by the administrator of the name servers that manage the domain space and resource data The following figure shows an example of a domain name space COLORS FLAVORS TRUTH NATURAL RED BLUE GREEN CHOCOLATE VANILLA STRAWBERRY In this example the root domain has three immediate subdomains COLORS FLAVORS and TRUTH The FLAVORS domain has one immediate subdomain named NATURAL FLAVORS All of the leaves are also Mockapetris Page 7 RFC 882 November 1983 Domain Names Concepts and Facilities domains This domain tree has the names the root COLORS RED COLORS BLUE COLORS GREEN COLORS FLAVORS NATURAL FLAVORS CHOCOLATE NATURAL FLAVORS VANILLA NATURAL FLAVORS STRAWBERRY NATURAL FLAVORS and TRUTH If we wished to add a new domain of ARTIFICIAL under FLAVORS FLAVORS would typically be the administrative entity that would decide if we wished to create CHIP and MOCHA names under CHOCOLATE CHOCOLATE NATURAL FLAVORS would typically be the appropriate administrative entity Resource set information A domain name identifies a set of resource information The set of resource information associated with a particular name is composed of separate resource records RRs Each resource record has the following major components The domain name which identifies resource set that holds this record and hence the owner of the information For example a RR that specifies a host address has a domain name the specifies the host having that address Thus F ISI ARPA might be the owner of a RR which specified an address field of 10 2 0 52 Since name servers typically store their resource information in tree structures paralleling the organization of the domain space this information can usually be stored implicitly in the database however it is always included in each resource record carried in a message Other information used to manage the RR such as length fields timeouts etc This information is omitted in much of this memo but is discussed in 14 A resource type field that specifies the type of the resource in this resource record Types refer to abstract resources such as host addresses or mail delivery agents The type field is two octets long and uses an encoding that is standard throughout the domain name system A class field identifies the format of the resource data such as the ARPA Internet format IN or the Computer Science Network format CSNET for certain RR types such as address data Note that while the class may separate different protocol families networks etc it does not do so in all cases For example the IN class uses 32 bit IP addresses exclusively but the CSNET class uses 32 bit IP addresses X 25 addresses and phone numbers Thus the class field should be used as a guide for interpreting the resource data The class field is two octets long and uses an encoding that is standard throughout the domain name system Mockapetris Page 8 RFC 882 November 1983 Domain Names Concepts and Facilities Resource data that describes the resource The format of this data can be determined given the type and class fields but always starts with a two octet length field that allows a name server or resolver to determine the boundaries of the resource data in any transaction even if it cannot understand the resource data itself Thus name servers and resolvers can hold and pass on records which they cannot interpret The format of the internal data is restricted only by the maximum length of 65535 octets for example the host address record might specify a fixed 32 bit number for one class and a variable length list of addresses in another class While the class field in effect partitions the resource data in the domain name system into separate parallel sections according to class services can span class boundaries if they use compatible resource data formats For example the domain name system uses compatible formats for structure information and the mail data decouples mail agent identification from details of how to contact the agent e g host addresses This memo uses the following types in its examples A the host address associated with the domain name MF identifies a mail forwarder for the domain MD identifies a mail destination for the domain NS the authoritative name server for the domain SOA identifies the start of a zone of authority CNAME identifies the canonical name of an alias This memo uses the following classes in its examples IN the ARPA Internet system CS the CSNET system The first type of resource record holds a host name to host address binding Its fields are A information Mockapetris Page 9 RFC 882 November 1983 Domain Names Concepts and Facilities The content of the class specific information varies according to the value in the CLASS field for the ARPA Internet it is the 32 bit ARPA Internet address of the host for the CSNET it might be the phone number of the host For example F ISI ARPA might have two A records of the form F ISI ARPA A IN 10 2 0 52 and F ISI ARPA A CS 213 822 2112 Note that the data formats for the A type are class dependent and the Internet address and phone number formats shown above are for purposes of illustration only The actual data formats are specified in 14 For example CS class data for type A records might actually be a list of Internet addresses phone numbers and TELENET addresses The mail forwarder MF and mail delivery MD records have the following format MD MF The field is a domain name of the host that will handle mail note that this domain name may be completely different from the domain name which names the resource record For example F ISI ARPA might have two records of the form F ISI ARPA MD IN F ISI ARPA and F ISI ARPA MF IN B ISI ARPA These records mean that mail for F ISI ARPA can either be delivered to the host F ISI ARPA or forwarded to B ISI ARPA which will accept responsibility for its eventual delivery In principle an additional name lookup is required to map the domain name of the host to the appropriate address in practice this information is usually returned in the response to the mail query The SOA and NS types of resource records are used to define limits Mockapetris Page 10 RFC 882 November 1983 Domain Names Concepts and Facilities of authority The domain name given by the owner field of a SOA record is the start of a zone the domain name given by the owner field of a NS record identifies a point in the name space where authority has been delegated and hence marks the zone boundary Except in the case where a name server delegates authority to itself the SOA identifies the top limit of authority and NS records define the first name outside of a zone These resource records have a standard format for all of the name space SOA NS The SOA record marks the start of a zone when it is present in a database the NS record both marks the end of a zone started by an SOA if a higher SOA is present and also points to a name server that has a copy of the zone specified by the in the SOA record specifies the original source of the information in the zone and other information used by name servers to organize their activities SOA records are never cached otherwise they would create false zones they can only be created in special name server maintenance operations The NS record says that a name server which is authoritative for records of the given CLASS can be found at Queries Queries to a name server must include a domain name which identifies the target resource set QNAME and the type and class of desired resource records The type and class fields in a query can include any of the corresponding type and class fields that are defined for resource records in addition the query type QTYPE and query class QCLASS fields may contain special values that match more than one of the corresponding fields in RRs For example the QTYPE field may contain MAILA matches all mail agent RRs e g MD and MF matches any RR type Mockapetris Page 11 RFC 882 November 1983 Domain Names Concepts and Facilities The QCLASS field may contain matches any RR class Using the query domain name QTYPE and QCLASS the name server looks for matching RRs In addition to relevant records the name server may return RRs that point toward a name server that has the desired information or RRs that are expected to be useful in interpreting the relevant RRs For example a name server that doesn t have the requested information may know a name server that does a name server that returns a domain name in a relevant RR may also return the RR that binds that domain name to an address Note that the QCLASS construct requires special interpretation regarding authority Since a name server may not know all of the classes available in the domain system it can never know if it is authoritative for all classes Hence responses to QCLASS queries can never be authoritative Example space For purposes of exposition the following name space is used for the remainder of this memo DDN ARPA CSNET JCS ARMY NAVY UDEL UCI DTI MIT ISI UDEL NBS DMS AI A B F Mockapetris Page 12 RFC 882 November 1983 Domain Names Concepts and Facilities NAME SERVERS Introduction Name servers store a distributed database consisting of the structure of the domain name space the resource sets associated with domain names and other information used to coordinate actions between name servers In general a name server will be an authority for all or part of a particular domain The region covered by this authority is called a zone Name servers may be responsible for no authoritative data and hence have no zones or may have several zones When a name server has multiple zones the zones may have no common borders or zones may be contiguous While administrators should not construct overlapping zones and name servers must defend against overlapping zones overlapping is regarded as a non fatal flaw in the database Hence the measures taken to protect against it are omitted for the remainder of this memo A detailed discussion can be found in 14 When presented with a query for a domain name over which it has authority a name server returns the desired resource information or an indication that the query refers to a domain name or resource that does not exist If a name server is presented with a query for a domain name that is not within its authority it may have the desired information but it will also return a response that points toward an authoritative name server If a name server is not an authority for a query it can never return a negative response There is no requirement that a name server for a domain reside in a host which has a name in the same domain although this will usually be the case There is also no restriction on the number of name servers that can have authority over a particular domain most domains will have redundant authoritative name servers The assumption is that different authoritative copies are identical even though inconsistencies are possible as updates are made Name server functions are designed to allow for very simple implementations of name servers The simplest name server has a static set of information and uses datagrams to receive queries and return responses More sophisticated name server implementations can improve the performance of their clients by caching information from other domains Although this information can be acquired in a number of ways the normal method is to store the information acquired by a Mockapetris Page 13 RFC 882 November 1983 Domain Names Concepts and Facilities resolver when the resolver consults other name servers In a sophisticated host the resolver and name server will coordinate their actions and use a shared database This cooperation requires the incorporation of a time to live TTL field in all cached resource records Caching is discussed in the resolver section of this memo this section is devoted to the actions of a name servers that don t cache In order to free simple name servers of the requirement of managing these timeouts simple name servers should only contain resource records that are expected to remain constant over very long periods or resource records for which the name server is an authority In the following discussion the TTL field is assumed to be stored in the resource record but is omitted in descriptions of databases and responses in the interest of clarity Authority and administrative control of domains Although we want to have the potential of delegating the privileges of name space management at every node we don t want such delegation to be required Hence we introduce the concept of authority Authority is vested in name servers A name server has authority over all of its domain until it delegates authority for a subdomain to some other name server Any administrative entity that wishes to establish its own domain must provide a name server and have that server accepted by the parent name server i e the name server that has authority over the place in the domain name space that will hold the new domain While the principles of authority allow acceptance to be at the discretion of parent name servers the following criteria are used by the root and are recommended to all name servers because they are responsible for their children s actions 1 It must register with the parent administrator of domains 2 It must identify a responsible person 3 In must provide redundant name servers The domain name must be registered with the administrator to avoid name conflicts and to make the domain related information available to other domains The central administrator may have further requirements and a domain is not registered until the central administrator agrees that all requirements are met There must be a responsible person associated with each domain to Mockapetris Page 14 RFC 882 November 1983 Domain Names Concepts and Facilities be a contact point for questions about the domain to verify and update the domain related information and to resolve any problems e g protocol violations with hosts in the domain The domain must provide redundant i e two or more name servers to provide the name to address resolution service These name servers must be accessible from outside the domain as well as inside and must resolve names for at least all the hosts in the domain Once the central administrator is satisfied he will communicate the existence to the appropriate administrators of other domains so that they can incorporate NS records for the new name server into their databases Name server logic The processing steps that a name server performs in responding to a query are conceptually simple although implementations may have internal databases that are quite complex For purposes of explanation we assume that the query consists of a type QTYPE a class QCLASS and a domain name QNAME we assume that the name server stores its RRs in sets where each set has all of the RRs for a particular domain Note that this database structure and the following algorithms are meant to illustrate one possible implementation rather than a specification of how all servers must be implemented The following notation is used ord DOMAIN NAME returns the number of labels in DOMAIN NAME findset DOMAIN NAME returns a pointer to the set of stored RRs for DOMAIN NAME or NULL if there is no such information set POINTER refers to a set located previously by findset where POINTER is the value returned by findset relevant QTYPE TYPE returns true if a

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0882.txt (2016-02-14)
    Open archived version from archive


  • may not use responses of this type and should repeat the query using virtual circuits instead of datagrams Getting a response in which the response code is non zero Mailers are expected to do something reasonable in the face of an error The behaviour for each type of error is not specified here but implementors should note that different types of errors should probably be treated differently For example a response code of non existent domain should probably cause the message to be returned to the sender as invalid while a response code of server failure should probably cause the message to be retried later There is one other special case If the response contains an answer which is a CNAME RR it indicates that REMOTE is actually an alias for some other domain name The query should be repeated with the canonical domain name If the response does not contain an error response and does not contain aliases its answer section should be a possibly zero length list of MX RRs for domain name REMOTE or REMOTE s true domain name if REMOTE was a alias The next section describes how this list is interpreted Interpreting the List of MX RRs NOTE This section only discusses how mailers choose which names to try to deliver a message to working from a list of RR s It does not discuss how the mailers actually make delivery Where ever delivering a message is mentioned all that is meant is that the mailer should do whatever it needs to do to transfer a message to a remote site given a domain name for that site For example an SMTP mailer will try to get an address for the domain name which involves another query to the domain system and then if it gets an address connect to the SMTP TCP port The mechanics of actually transferring the message over the network to the address associated with a given domain name is not within the scope of this memo It is possible that the list of MXs in the response to the query will be empty This is a special case If the list is empty mailers should treat it as if it contained one RR an MX RR with a preference value of 0 and a host name of REMOTE I e REMOTE is its only MX In addition the mailer should do no further processing on the list but should attempt to deliver the message to REMOTE The idea Partridge Page 4 RFC 974 January 1986 Mail Routing and the Domain System here is that if a domain fails to advertise any information about a particular name we will give it the benefit of the doubt and attempt delivery If the list is not empty the mailer should remove irrelevant RR s from the list according to the following steps Note that the order is significant For each MX a WKS query should be issued to see if the domain name

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0974.txt (2016-02-14)
    Open archived version from archive



  •