<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="edb36438cc06fead" weblate-flags="read-only">
        <source>This is an unpolished draft of the third edition of this e-book. If you find any error or have suggestions to improve the text, please create an issue via https://github.com/CNP3/ebook/issues?milestone=3 or help us by providing pull requests to close the existing issues.</source>
        <target state="translated">This is an unpolished draft of the third edition of this e-book. If you find any error or have suggestions to improve the text, please create an issue via https://github.com/CNP3/ebook/issues?milestone=3 or help us by providing pull requests to close the existing issues.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">8</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="12b31b949df84d97" weblate-flags="read-only">
        <source>The reference models</source>
        <target state="translated">The reference models</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">12</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="03844f647d2f13ab" weblate-flags="read-only">
        <source>Given the growing complexity of computer networks, during the 1970s network researchers proposed various reference models to facilitate the description of network protocols and services. Of these, the Open Systems Interconnection (OSI) model [Zimmermann80]_ was probably the most influential. It served as the basis for the standardization work performed within the :term:`ISO` to develop global computer network standards. The reference model that we use in this book can be considered as a simplified version of the OSI reference model [#fiso-tcp]_.</source>
        <target state="translated">Given the growing complexity of computer networks, during the 1970s network researchers proposed various reference models to facilitate the description of network protocols and services. Of these, the Open Systems Interconnection (OSI) model [Zimmermann80]_ was probably the most influential. It served as the basis for the standardization work performed within the :term:`ISO` to develop global computer network standards. The reference model that we use in this book can be considered as a simplified version of the OSI reference model [#fiso-tcp]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">14</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d453e534d52ebb41" weblate-flags="read-only">
        <source>The five layers reference model</source>
        <target state="translated">The five layers reference model</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="88a65c0b1afa01ab" weblate-flags="read-only">
        <source>Our reference model is divided into five layers, as shown in the figure below.</source>
        <target state="translated">Our reference model is divided into five layers, as shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">21</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2162f995ccfca05e" weblate-flags="read-only">
        <source>The Physical layer</source>
        <target state="translated">The Physical layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">42</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="922f48a61bda5c05" weblate-flags="read-only">
        <source>Starting from the bottom, the first layer is the Physical layer. Two communicating devices are linked through a physical medium. This physical medium is used to transfer an electrical or optical signal between two directly connected devices.</source>
        <target state="translated">Starting from the bottom, the first layer is the Physical layer. Two communicating devices are linked through a physical medium. This physical medium is used to transfer an electrical or optical signal between two directly connected devices.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">46</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a6fe2fe1245147ee" weblate-flags="read-only">
        <source>An important point to note about the Physical layer is the service that it provides. This service is usually an unreliable service that allows the users of the Physical layer to exchange bits. The unit of information transfer in the Physical layer is the bit. The Physical layer service is unreliable because :</source>
        <target state="translated">An important point to note about the Physical layer is the service that it provides. This service is usually an unreliable service that allows the users of the Physical layer to exchange bits. The unit of information transfer in the Physical layer is the bit. The Physical layer service is unreliable because :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">48</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0afabbefcaff604a" weblate-flags="read-only">
        <source>the Physical layer may change, e.g. due to electromagnetic interference, the value of a bit being transmitted</source>
        <target state="translated">the Physical layer may change, e.g. due to electromagnetic interference, the value of a bit being transmitted</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">50</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0cc779d51c2c537b" weblate-flags="read-only">
        <source>the Physical layer may deliver `more` bits to the receiver than the bits sent by the sender</source>
        <target state="translated">the Physical layer may deliver `more` bits to the receiver than the bits sent by the sender</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">51</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="db6380792d335a49" weblate-flags="read-only">
        <source>the Physical layer may deliver `fewer` bits to the receiver than the bits sent by the sender</source>
        <target state="translated">the Physical layer may deliver `fewer` bits to the receiver than the bits sent by the sender</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">52</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a4790041b3c2e585" weblate-flags="read-only">
        <source>The Datalink layer</source>
        <target state="translated">The Datalink layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">72</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2cf85e7d3dddc141" weblate-flags="read-only">
        <source>The `Datalink layer` builds on the service provided by the underlying physical layer. The `Datalink layer` allows two hosts that are directly connected through the physical layer to exchange information. The unit of information exchanged between two entities in the `Datalink layer` is a frame. A frame is a finite sequence of bits. Some `Datalink layers` use variable-length frames while others only use fixed-length frames. Some `Datalink layers` provide a connection-oriented service while others provide a connectionless service. Some `Datalink layers` provide reliable delivery while others do not guarantee the correct delivery of the information.</source>
        <target state="translated">The `Datalink layer` builds on the service provided by the underlying physical layer. The `Datalink layer` allows two hosts that are directly connected through the physical layer to exchange information. The unit of information exchanged between two entities in the `Datalink layer` is a frame. A frame is a finite sequence of bits. Some `Datalink layers` use variable-length frames while others only use fixed-length frames. Some `Datalink layers` provide a connection-oriented service while others provide a connectionless service. Some `Datalink layers` provide reliable delivery while others do not guarantee the correct delivery of the information.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">74</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="93277c024f816c06" weblate-flags="read-only">
        <source>An important point to note about the `Datalink layer` is that although the figure below indicates that two entities of the `Datalink layer` exchange frames directly, in reality this is slightly different. When the `Datalink layer` entity on the left needs to transmit a frame, it issues as many `Data.request` primitives to the underlying `physical layer` as there are bits in the frame. The physical layer will then convert the sequence of bits in an electromagnetic or optical signal that will be sent over the physical medium. The `physical layer` on the right hand side of the figure will decode the received signal, recover the bits and issue the corresponding `Data.indication` primitives to its `Datalink layer` entity. If there are no transmission errors, this entity will receive the frame sent earlier.</source>
        <target state="translated">An important point to note about the `Datalink layer` is that although the figure below indicates that two entities of the `Datalink layer` exchange frames directly, in reality this is slightly different. When the `Datalink layer` entity on the left needs to transmit a frame, it issues as many `Data.request` primitives to the underlying `physical layer` as there are bits in the frame. The physical layer will then convert the sequence of bits in an electromagnetic or optical signal that will be sent over the physical medium. The `physical layer` on the right hand side of the figure will decode the received signal, recover the bits and issue the corresponding `Data.indication` primitives to its `Datalink layer` entity. If there are no transmission errors, this entity will receive the frame sent earlier.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">76</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0a30f2d325e2c3df" weblate-flags="read-only">
        <source>The Network layer</source>
        <target state="translated">The Network layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">96</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="be8ae004dec92b06" weblate-flags="read-only">
        <source>The `Datalink layer` allows directly connected hosts to exchange information, but it is often necessary to exchange information between hosts that are not attached to the same physical medium. This is the task of the `network layer`. The `network layer` is built above the `datalink layer`. Network layer entities exchange `packets`. A `packet` is a finite sequence of bytes that is transported by the datalink layer inside one or more frames. A packet usually contains information about its origin and its destination, and usually passes through several intermediate devices called routers on its way from its origin to its destination.</source>
        <target state="translated">The `Datalink layer` allows directly connected hosts to exchange information, but it is often necessary to exchange information between hosts that are not attached to the same physical medium. This is the task of the `network layer`. The `network layer` is built above the `datalink layer`. Network layer entities exchange `packets`. A `packet` is a finite sequence of bytes that is transported by the datalink layer inside one or more frames. A packet usually contains information about its origin and its destination, and usually passes through several intermediate devices called routers on its way from its origin to its destination.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">100</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="60b733b6cd05bed0" weblate-flags="read-only">
        <source>The Transport layer</source>
        <target state="translated">The Transport layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">131</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ea15fa6c83959283" weblate-flags="read-only">
        <source>The network layer enables hosts to reach each others. However, different communication flows can take place between the same hosts. These communication flows might have different needs (some require reliable delivery, other not) and need to be distinguished. Ensuring an identification of a communication flow between two given hosts is the task of the `transport layer`. `Transport layer` entities exchange `segments`. A segment is a finite sequence of bytes that are transported inside one or more packets. A transport layer entity issues segments (or sometimes part of segments) as `Data.request` to the underlying network layer entity.</source>
        <target state="translated">The network layer enables hosts to reach each others. However, different communication flows can take place between the same hosts. These communication flows might have different needs (some require reliable delivery, other not) and need to be distinguished. Ensuring an identification of a communication flow between two given hosts is the task of the `transport layer`. `Transport layer` entities exchange `segments`. A segment is a finite sequence of bytes that are transported inside one or more packets. A transport layer entity issues segments (or sometimes part of segments) as `Data.request` to the underlying network layer entity.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">133</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="32f88b5b7860b791" weblate-flags="read-only">
        <source>There are different types of transport layers. The most widely used transport layers on the Internet are :term:`TCP`, that provides a reliable connection-oriented bytestream transport service, and :term:`UDP`, that provides an unreliable connection-less transport service.</source>
        <target state="translated">There are different types of transport layers. The most widely used transport layers on the Internet are :term:`TCP`, that provides a reliable connection-oriented bytestream transport service, and :term:`UDP`, that provides an unreliable connection-less transport service.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">135</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e8b28031aa90a28c" weblate-flags="read-only">
        <source>The Application layer</source>
        <target state="translated">The Application layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">164</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="246ef0ae15f32746" weblate-flags="read-only">
        <source>The upper layer of our architecture is the `Application layer`. This layer includes all the mechanisms and data structures that are necessary for the applications. We will use Application Data Unit (ADU) or the generic Service Data Unit (SDU) term to indicate the data exchanged between two entities of the Application layer.</source>
        <target state="translated">The upper layer of our architecture is the `Application layer`. This layer includes all the mechanisms and data structures that are necessary for the applications. We will use Application Data Unit (ADU) or the generic Service Data Unit (SDU) term to indicate the data exchanged between two entities of the Application layer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">168</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f1e9c0db7034f48b" weblate-flags="read-only">
        <source>In the remaining chapters of this text, we will often refer to the information exchanged between entities located in different layers. To avoid any confusion, we will stick to the terminology defined earlier, i.e. :</source>
        <target state="translated">In the remaining chapters of this text, we will often refer to the information exchanged between entities located in different layers. To avoid any confusion, we will stick to the terminology defined earlier, i.e. :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">201</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f63ae9d73e44622b" weblate-flags="read-only">
        <source>physical layer entities exchange bits</source>
        <target state="translated">physical layer entities exchange bits</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">203</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8db0a40f8840a773" weblate-flags="read-only">
        <source>datalink layer entities exchange *frames*</source>
        <target state="translated">datalink layer entities exchange *frames*</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">204</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fc58ffd4c389110f" weblate-flags="read-only">
        <source>network layer entities exchange *packets*</source>
        <target state="translated">network layer entities exchange *packets*</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">205</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fdcd73768f7a2de5" weblate-flags="read-only">
        <source>transport layer entities exchange *segments*</source>
        <target state="translated">transport layer entities exchange *segments*</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">206</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="53a9f1395e850758" weblate-flags="read-only">
        <source>application layer entities exchange *SDUs*</source>
        <target state="translated">application layer entities exchange *SDUs*</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">207</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="11d7b7cef271f1fa" weblate-flags="read-only">
        <source>Reference models</source>
        <target state="translated">Reference models</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">212</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eccf8160e289e34b" weblate-flags="read-only">
        <source>Two reference models have been successful in the networking community : the OSI reference model and the TCP/IP reference model. We discuss them briefly in this section.</source>
        <target state="translated">Two reference models have been successful in the networking community : the OSI reference model and the TCP/IP reference model. We discuss them briefly in this section.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">215</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8ca9dbc4dc84bc36" weblate-flags="read-only">
        <source>The TCP/IP reference model</source>
        <target state="translated">The TCP/IP reference model</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">219</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="687d7cd9ab7d9d70" weblate-flags="read-only">
        <source>In contrast with OSI, the TCP/IP community did not spend a lot of effort defining a detailed reference model; in fact, the goals of the Internet architecture were only documented after TCP/IP had been deployed [Clark88]_. :rfc:`1122`, which defines the requirements for Internet hosts, mentions four different layers. Starting from the top, these are :</source>
        <target state="translated">In contrast with OSI, the TCP/IP community did not spend a lot of effort defining a detailed reference model; in fact, the goals of the Internet architecture were only documented after TCP/IP had been deployed [Clark88]_. :rfc:`1122`, which defines the requirements for Internet hosts, mentions four different layers. Starting from the top, these are :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">221</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7c1ca59f9c2f2755" weblate-flags="read-only">
        <source>the Application layer</source>
        <target state="translated">the Application layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">223</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9dfa0b8c44ae2351" weblate-flags="read-only">
        <source>the Transport layer</source>
        <target state="translated">the Transport layer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">224</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ab8cd908d3a7f54d" weblate-flags="read-only">
        <source>the Internet layer which is equivalent to the network layer of our reference model</source>
        <target state="translated">the Internet layer which is equivalent to the network layer of our reference model</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">225</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ebd929c9fc5b4721" weblate-flags="read-only">
        <source>the Link layer which combines the functions of the physical and datalink layers of our five-layer reference model</source>
        <target state="translated">the Link layer which combines the functions of the physical and datalink layers of our five-layer reference model</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">226</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eb71565a8d9deb13" weblate-flags="read-only">
        <source>Besides this difference in the lower layers, the TCP/IP reference model is very close to the five layers that we use throughout this document.</source>
        <target state="translated">Besides this difference in the lower layers, the TCP/IP reference model is very close to the five layers that we use throughout this document.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">228</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d1a0f277ee54bba5" weblate-flags="read-only">
        <source>The OSI reference model</source>
        <target state="translated">The OSI reference model</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">233</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="288a2218db122120" weblate-flags="read-only">
        <source>Compared to the five layers reference model explained above, the :term:`OSI` reference model defined in [X200]_ is divided in seven layers. The four lower layers are similar to the four lower layers described above. The OSI reference model refined the application layer by dividing it in three layers :</source>
        <target state="translated">Compared to the five layers reference model explained above, the :term:`OSI` reference model defined in [X200]_ is divided in seven layers. The four lower layers are similar to the four lower layers described above. The OSI reference model refined the application layer by dividing it in three layers :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">235</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="67877fc9b4a49045" weblate-flags="read-only">
        <source>the `Session layer`. The Session layer contains the protocols and mechanisms that are necessary to organize and to synchronize the dialogue and to manage the data exchange of presentation layer entities. While one of the main functions of the transport layer is to cope with the unreliability of the network layer, the session's layer objective is to hide the possible failures of transport-level connections to the upper layer higher. For this, the Session Layer provides services that allow establishing a session-connection, to support in-order data exchange (including mechanisms that allow recovering from the abrupt release of an underlying transport connection), and to release the connection in an orderly manner.</source>
        <target state="translated">the `Session layer`. The Session layer contains the protocols and mechanisms that are necessary to organize and to synchronize the dialogue and to manage the data exchange of presentation layer entities. While one of the main functions of the transport layer is to cope with the unreliability of the network layer, the session's layer objective is to hide the possible failures of transport-level connections to the upper layer higher. For this, the Session Layer provides services that allow establishing a session-connection, to support in-order data exchange (including mechanisms that allow recovering from the abrupt release of an underlying transport connection), and to release the connection in an orderly manner.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">237</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="351aa672a0c45ea9" weblate-flags="read-only">
        <source>the `Presentation layer` was designed to cope with the different ways of representing information on computers. There are many differences in the way computer store information. Some computers store integers as 32 bits field, others use 64 bits field and the same problem arises with floating point number. For textual information, this is even more complex with the many different character codes that have been used [#funicode]_. The situation is even more complex when considering the exchange of structured information such as database records. To solve this problem, the Presentation layer provides a common representation of the data transferred. The :term:`ASN.1` notation was designed for the Presentation layer and is still used today by some protocols.</source>
        <target state="translated">the `Presentation layer` was designed to cope with the different ways of representing information on computers. There are many differences in the way computer store information. Some computers store integers as 32 bits field, others use 64 bits field and the same problem arises with floating point number. For textual information, this is even more complex with the many different character codes that have been used [#funicode]_. The situation is even more complex when considering the exchange of structured information such as database records. To solve this problem, the Presentation layer provides a common representation of the data transferred. The :term:`ASN.1` notation was designed for the Presentation layer and is still used today by some protocols.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">238</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bde4543ac04bceac" weblate-flags="read-only">
        <source>the `Application layer` that contains the mechanisms that do not fit in neither the Presentation nor the Session layer. The OSI Application layer was itself further divided in several generic service elements.</source>
        <target state="translated">the `Application layer` that contains the mechanisms that do not fit in neither the Presentation nor the Session layer. The OSI Application layer was itself further divided in several generic service elements.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">239</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">275</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="449af40bfb3b7729" weblate-flags="read-only">
        <source>An interesting historical discussion of the OSI-TCP/IP debate may be found in [Russel06]_</source>
        <target state="translated">An interesting historical discussion of the OSI-TCP/IP debate may be found in [Russel06]_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">276</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="651e6f11ac63b82b" weblate-flags="read-only">
        <source>There is now a rough consensus for the greater use of the Unicode_ character format. Unicode can represent more than 100,000 different characters from the known written languages on Earth. Maybe one day, all computers will only use Unicode to represent all their stored characters and Unicode could become the standard format to exchange characters, but we are not yet at this stage today.</source>
        <target state="translated">There is now a rough consensus for the greater use of the Unicode_ character format. Unicode can represent more than 100,000 different characters from the known written languages on Earth. Maybe one day, all computers will only use Unicode to represent all their stored characters and Unicode could become the standard format to exchange characters, but we are not yet at this stage today.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../principles/referencemodels.rst</context>
          <context context-type="linenumber">278</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
