Introduction

On Monday, we started talking about the presentation layer.
We said this layer allows a sender application to encode integers, dates, images, etc. into an agreed format so that it can be transmitted over the network to a receiving host where it can be decoded into constituents usable by the receiving application.
We then went over design choices that one might have for a presentation layer format: what types can be encoded/decoded, what should be the conversion strategy to and from this format if have multiple different sending/receiving architectures, should the data be tagged or untagged, and how should the sender/receiver stubs be implemented.
We looked at XDR, the presentation format used by SUN-RPC, and how it addressed these questions.
We also casually introduced XML (will have on slides today).
We start today by considering some more presentation formats and then we look at compression schemes.

ASN.1

Abstract Syntax Notation One (ASN.1) (created in 1984) is an ISO standard that defines in its Basic Encoding Rules sub-part a representation for data sent over a network.
It supports C-types without function pointers, it defines a canonical intermediate form, and uses type tags.
Its stubs can be either interpreted or compiled.
ASN.1 BER is used by the Simple Network Management Protocol (SNMP).
A data item in ASN.1 BER is a triple of the form:
```
(tag, length, value)
```
where tag is usually an 8-bit field -- although multi-byte fields can be supported, length is how many bytes in value, and value contains the actual data.
Composite types such as struct's are made by nesting primitive types.
The top image above shows how an ASN.1 BER integer value might be stored. The type tag INT is a 1 byte code for a signed integers, the length is 1 byte and has value 4. The value itself is stored in as 32-bit big endian using 2's complement (given positive x, -x is obtained by adding 1 to x then set high bit of 32 bits to 1 and invert all other bits).
The next image shows an example of how a compound type might stored.
If the length of the value is going to be more than 127, the high bit of length byte is 1, the remaining 7 bits say how long the length field will be in bytes. This is followed by the length field and then the data. This is illustrated in the last image pair above.

NDR

Network Data Representation (NDR) is the data encoding standard used in Distributed Computing Environment (DCE) (Chapelle 1993).
Recall DCE is used in ActiveX, DCOM, and Corba.
NDR uses the receiver-makes-right approach to convert between machine architectures. To do this it inserts an architecture tags at the front of each message sent in NDR.
Individual items in NDR are untagged.
NDR uses a compiler to generate stubs.
This compiler takes a description of a program written in the Interface Definition Language (IDL) and generates the necessary stubs.
IDL looks similar to C and essentially supports the C-type system.
The image above shows the components of the NDR architecture tag:
- IntegrRep defines the format of all integers contained in the message. 0 indicates big-endian, 1 little-endian.
- CharRep says the Character format. 0 means ASCII, 1 means EBCDIC.
- FloatRep defines the floating point representation. 0 means IEEE 754, 1 means VAX, 2 means Cray, 3 means IBM.
- The last two bytes are reserved for future use.

Protocol Buffers (ProtoBufs)

Protocol Buffers (Protobufs, for short) provide a language-neutral and platform-neutral way of serializing data, commonly used with gRPC.
They use a tagged strategy, with a canonical intermediate form, where the stub on both sides is generated from a shared .proto file.

ProtoBufs use a simple C-like syntax. As an example,

message Person {
      required string name = 1;
      required int32 id = 2;
      optional string email = 3;
      enum PhoneType {
          MOBILE = 0;
          HOME = 1;
          WORK = 2;
      }
      message PhoneNumber {
          required string number = 1;
          optional PhoneType type = 2 [default = HOME];
      }
      required PhoneNumber phone = 4;
  }

The message keyword can be thought of as like a typedef struct in C.
Each field is assigned a number (for example, required int32 id = 2;) to ensure uniqueness of that field should the spec change.
Note every field is specified as being required or optional.
Integers are encoded as varints (variable length integers). The high order bit in each byte in this encoding indicates if the number continues (1) or not (0).
For example, 2 is encoded as 0000 0010. The number 365 (1 0110 1101 in binary) is encoded as 1110 1101 0000 0010

XML

So far we have been discussing the presentation formatting problem from the perspective of RPC: How one encodes primitive types and compound structures so that they can be sent from a client program to a server program.
This problem also occurs in other settings.
For example, how does a web server describe a Web page so that any number of different browsers know what to display on the screen?
For web pages, the answer is the HyperText Markup Language (HTML).
Often web applications need to be able to communicate with each other and understand each other's data.
For example, an e-commerce site might need to talk to a shipping company's website to allow a customer to track a package without ever leaving the e-commerce site.
This kind of communication often looks similar to RPC calls, and such communication is often enabled using the Extensible Markup Language (XML) -- a way to describe the data being exchanged between Web Apps.

Markup Languages

Markup languages, of which HTML and XML are examples, represent data as text.
Text tags known as markup are intermingled with the data to express information about the data.
In the case of HTML, markup roughly says something about the meaning of the text as a unit in natural language writing. For example, the <p> tag indicates a paragraph.
In XML, the markup is used to express type and structure of the data.
XML is actually a framework for defining markup languages. You can define the HTML language in XML (the result is called XHTML to distinguish it from specs for HTML not written using XML).

XML Syntax

Below is an example XML document:

<?xml version="1.0"?>
  <employee>
     <name>John Doe</name>
     <title>Head Bottle Washer</title>
     <id>123456789</id>
     <hiredate>
        <day>5</day>
        <month>June</month>
        <year>1986</year>
     </hiredate>
  </employee>

It might be stored in a file with a name like employee.xml.
The first line indicates the version of XML in use, the remaining lines represent four fields that make up an employee record, the last of which is the hiredate. This last field is made up of three subfields.
So we see XML syntax allow as for a nested structure of tag value pairs. Tag markup is used to delimit values: <tag_name>some_value</tag_name> that we want some_value to be of tag_name type.

XML Schema

XML Schema is the XML language used to specify what are the allowed tag markups that can occur in a given XML document.
One can write a single XML Parser which can take a schema and an XML document and parse out the contents accordingly.

Below is an example XML Schema Document file which might be used to specify employee records such as the kind we saw on the previous slide:

<?xml version="1.0"?>
  <schema xmlns="http://www.w3.org/2001/XMLSchema">
    <element name="employee">
      <complexType>
        <sequence>
          <element name="name" type="string"/>
          <element name="title" type="string"/>
          <element name="id" type="string"/>
          <element name="hiredate">
            <complexType>
              <sequence>
                <element name="day" type="integer"/>
                <element name="month" type="string"/>
                <element name="year" type="integer"/>
              </sequence>
            </complexType>
          </element>
        </sequence>
      </complexType>
    </element>
</schema>

Notice within the open tag markup we have attribute="attribute_value". These are called attributes and can be used to narrow the behavior of a markup element.
So <element name="title" type="string"/> says we are defining a new tag title whose contents can be strings.
<element ... /> is called the short close tag abbreviation for <element ... ></element>

XML Namespaces

XML has to solve the name clash problem.
This problem might arise when one wants to have a single XML document but use the tags from more than one XML language.
For example, we might want to write an XHTML document using Employee document wihtin and both of these languages share the title tag.
To solve this problem, XML uses XML Namespaces.
An open tag can specify the allowed namespaces within it using the xmlns attribute or xmlns:abbreviation attributes.
We could solve the XHTML and Employee example problem above, by putting in the top <html> tag of the html document the following:
```
<html 
   xmlns="http://www.w3.org/1999/xhtml"
   xmlns:emp="http://www.example.com/employee"
>
```
This says if a tag doesn't begin with a namespace abbreviation assume it is html, if it uses the abbreviation emp then it is from the employee schema. Notice namespaces to specify languages look like URI's.
The below is an examplee employee title tag which might occur with the html tag above:
```
<emp:title>Head Bottle Washer</emp:title>
```

In-Class Exercise

Make an example XML document of a business card.
Make an example XML Schema which specifies the allowed tags business card documents should use.
Please post your solution to the May 3 In-Class Exercise Thread.

Multimedia Data and Compression

Multimedia data such as audio, video, and images make up the majority of web traffic.
Their transmission across the internet is made possible because not only do we have fixed formats for the media items, but also because of the use of compression technology.
At its heart, compression involves taking a string of bits and writing it down using a shorter string of bits.
Consider `n`-bit strings. There are `2^n` many n-bit strings, but only `1+2+2^2 + 2^{n-1} = 2^n-1` many strings of shorter length. So in general we can't expect a single compression program to work in all circumstances.
Most strings don't represent audio, video or images data, so one could expect to find a shorter way to encode just these strings.
For audio, video, images, we also just need to represent the perceptible details of the item in question. So compression of these kinds of data with relatively short strings is possible because for example there might be many n-bit images that look alike to humans.
Compression is often classified as lossless (the original data can be exactly reconstructed from the compressed source), or lossy in which data close to, with respect to some metric, the original data can be reconstructed from the compressed string.
We now look at compression techniques and then look at how these are used to build formats for multimedia data.

Lossless Compression Techniques

Below are some common lossless compression techniques:
Huffman Coding. Here we start with a document coded over some alphabet of symbols. For each symbol, we count its frequency and make a forest of nodes (symbol, frequency). Take the two trees in the forest with the least frequency and make a new tree with root labeled with the union of their symbols and the sum of their frequencies. hang a left branch labeled 0 from this root the higher frequency subtree, and hang a right branch labeled 1 the lower frequency subtree. Repeat this process until have a forest of 1 tree. Labels on paths down this tree to symbols are the codewords to use for that symbol.
Run Length Encoding. Replace consecutive occurences of a given symbol with only one copy, preceeded by a count of how many times the symbol occurred - the run length. For example, AAABBCDDDD might be encoded as 3A2B1C4D.
Differential Pulse Code Modulation (DPCM). Here we first output a reference symbol and then, for each symbol in the data, output the difference between that symbol and the reference symbol. For example, if A was the reference symbol, the string AAABBCDDDD would be encoded as A0001123333. We hope the numbers that follow are small so that they can be represented with a smaller number of bits. For example, 0-3 could each be represented with 2 bits.
Delta-Coding. Encode, after the start symbol, subsequent symbols as a difference from the preceding symbol. So AAABBCDDDD would be encoded as A001011000. Note for this example only need to encode the numbers 0 and 1, so we can do with 1 bit per symbol. The drawback of delta-coding is that it only works for non-decreasing sequences.
Dictionary-Based Methods. Lempel-Ziv (LZ) compression used in gzip and compress is the most famous example of this. In this approach, we build a dictionary (table) of variable length strings that we expect to find in the data, then replace these strings in the data with the corresponding index into the dictionary. For example, the word compression might be 4978th entry in the dictionary, so if a document had the string compression, we'd replace it with 4978 (as a 16 bit number). The LZ algorithm gives an online technique to build a dictionary while scanning the string to compress.

Multimedia Formats

We now look at two popular image formats, GIF (Graphics Interchange Format - 1987) and JPEG (Joint Photographic Experts Group - 1992), and how they make use of compression.
Image formats play a role in the formats for video.
We will look at one such format: MPEG (Moving Pictures Expert Group).
Similar techniques to video compression are also used for audio compression, so we'll look at one such format mp3.

Color Spaces

Each dot in a computer image (pixel) usually has a color associated to it.
A color space is a format to represent colors.
One popular choice is RGB (red, green, blue) - think of a color as being a 3D quantity which is a mixture of a red, green, and blue of different amounts.
The most common alternative to RGB is YUV.
Here Y is luminance -- roughly, the brightness of the pixel.
U and V contain the chrominance, the color information -- we'll get back to what these are a little later.

GIF

GIF (Steve Wilhite, CompuServe 1987) uses the RGB color space and starts with 8 bits for each of the R, G, and B value.
Rather than use 24 bits for each pixel, it tries to determine the top 256 colors which are closest to all of the colors in the image.
These 256 colors are stored in a 24*256 byte color palette table. Each pixel's 24 bit color in the starting image is then replace by the 8 bit index of a color in this palette that is closest to that color.
The GIF for the image we started with then consists of an LZ variant compression of the color palette version of the image.

Presentation Formats, Compression

Outline