2008-08-28 This introductory lecture gives the motivation for the course, some information about the people involved and the organization of the course, a high-level overview of the course's topics, and an overview of the assignments which are an important part of the course program.

• Building things …
• building is designing (with a lot of implicit design decisions)
• building things uncovers an essential set of constraints
• changing things should not be not too hard (if they are well-designed)
• … that actually work
• work means more than look good for the final demo
• how adaptable is an application to a changing environment?
• how easy is it to integrate new input and output channels?
• how easy can it be extended to meet new requirements?
• System design is (an important) part of design
• isolated design approaches (for example, UI only) will not deliver the best solutions
• an end-to-end view involves the complete view of a system
• Start building things as early as possible

• Star Architects are not typical
• they sell brand names and deliver high profile results
• most architects are more modest and less visible
• Architects must understand how things work
• a reasonable understanding of the disciplines involved
• an excellent understanding of disciplines have to interact
• negotiating between specialists for a good overall design
• Architects are guides
• they provide guidance for going in the right direction
• they can tell why this direction is the right direction
• they can explain why a wrong direction is wrong

• Understand Web technologies and their dependencies
• no need to become an expert in all of the areas
• the important part is understanding the dependencies
• Understand how to compare application architectures
• there is no best solution for any given problem
• every solution must be evaluated in terms of various constraints
• Next steps for your career in Web architecture
• understand how the back-end plumbing (a.k.a. XML) works in detail
• get involved in real-world projects in the ISD Clinic

• Broad overview of core Web technologies
• this is not a Web design or Web programming course
• Assignments working with various Web technologies
• how to setup and configure a Web server
• how to deliver client-specific content
• how to design client-specific styles
• using Ajax for creating more dynamic Web pages
• repurposing existing content for syndication
• Final project looking at a real-world case study
• apply a Web architecture view o a Web application architecture
• come up with an analysis of the strengths, weaknesses, opportunities, and threats

If the only tool you have is a hammer, you tend to see every problem as a nail.

Abraham Maslow

• People, and thus content creators, typically are lazy
• developing content and code for diverse users and clients is hard
• by making assumptions, this job can become considerably easier
• Tools often hide complexity and/or take away freedom
• they are good if tool users know what they are doing
• tool users should know alternatives and when to switch tools
• Tool makers provide support for lazy people
• built-in simplifications of the tool's target technology
• pre-packaged excuses why it is appropriate to use the tool

• How to apply for NSF grants
• Over $400 billion in grants each year
• PureEdge is required as the technology to fill out grant forms
• acquired by IBM and now called IBM Workplace Forms
• All of this probably looked nice for the final demo …
• Web forms do not provide all the features required by the specification
• offline editing of applications is not possible, Web forms work online only
• there is no built-in signing of form contents, but there are technologies for it

• Well, but not if you are using Vista …
• PureEdge is an IE plug-in for filling out forms online and offline
• plug-ins are specific for the browser for which they are developed
• plug-ins are specific for the OS on which they run

• Government authorities are (usually) concerned about accessibility
• restricting $400 billion of grant money to IE users only seems a bit restrictive
• is there a reasonable argument to be made for this restriction
• Grants.gov recommended to get a virtual PC to access the portal
• users have to buy virtual PC software
• users have to buy Windows to run on the virtual PC

• Grants.gov set up a Citrix server for grant applicants
• Citrix server licenses are not cheap to buy
• applicants still have to install the Citrix client (which is free)
• running a Citrix server farm is pretty expensive

• After some time, PureEdge for Mac was released, features include:
• occasional crashes and subsequent loss of any unsaved data
• inability to run on Mac OS version prior to 10.4.6

• Companies usually sell products, not just solutions
• Lock-in happens quickly and is hard to escape from later
• Lock-in usually carries a pretty high price tag
• Lock-in solutions can be good, but it is an important decision
• Standards-based solutions may lack some sophistication
• but often they may still be good enough to solve a problem
• being able to change the platform easily is a valuable asset

• The I.R.S. perspective
• electronic filing saves money and should be encouraged
• processing a paper version: $2.65
• processing an electronic submission: $0.29
• The company perspective
• have a monopoly for 2005-2009
• taxpayers paid $1.01 billion for submission fees
• the servers could not handle the load
• The taxpayer perspective
• IRS saves money, but taxpayers are charged
• electronic filing must go through a company

• Computer Science at Technical University of Berlin (TUB) (88-91)
• Ph.D. at ETH Zürich (92-97)
• Post-Doc at ICSI, Berkeley (97/98)
• book on Technical Foundations of the World Wide Web
• Various activities back in Switzerland (98-06)
• teaching at ETH Zürich and FHNW
• working as independent consultant (training, courses, consulting)
• research in various XML-related areas
• Professor at the School of Information (since Fall 2006)
• technical director of the Information and Service Design (ISD) program

• Course Web page: http://dret.net/lectures/web-fall08/
• bspace course Web page for additional information
• Course mailing list: web-fall08@bspace.berkeley.edu
• also available through the bspace mail tool
• the bspace mail tool supports role-based emails
• archived in the bspace email archive
• Letter grade based on assignments, mid-term exam, and final project

• Generated from Hotspot XML
• Designed for online presentation and use (lots of links!)
• Firefox Go Up allows easy navigation up one level
• Firefox Site Navigation Bar supports navigation of link links
• Firefox Link Widgets requires a bit more configuration (more flexibility)
• for printing, use a (all slides), and then s (smaller font) a couple of times
• A good real-world example for Web-based publishing
• Slidy/Kilauea is useful, but there is no support for structures and hyperlinking
• Hotspot adds these features by adding an XSLT transformation
• Hotspot is useful, but there is no interface (XML editing only)

• Online Glossary at http://dret.net/glossary/
• suggestions, updates, corrections are very welcome (really!)
• another exercise in how to use XML and XSLT for information management
• Bibliography at http://dret.net/biblio/
• suggestions, updates, corrections are very welcome (really!)
• produced by an XML-centric system for managing bibliography data
• The World Wide Web Consortium (W3C)
• headed by Tim-Berners Lee, inventor of the Web (with Robert Cailliau)
• The Internet Engineering Task Force (IETF)
• mainly Internet standards, but also responsible for URIs and HTTP

2008-09-02 Architecture? · Architecture Summary Architecture The Web's architecture has very simple principles revolving around the ideas of placing a heavy emphasis on a consistent and global identification mechanism for resources, a standardized way of how resource representations can be retrieved, and a standardized way of how resource representations should be usable by using standardized media types. This lecture presents an overview of these architectural principles and illustrates them with using blogs as an example of Web-based applications.

Summary of Ian Jacobs, Norman Walsh, Architecture of the World Wide Web, Volume One, World Wide Web Consortium, Recommendation REC-webarch-20041215, December 2004

• Examples (or counter-examples) for the following principles, practices, and constraints:
• URIs identify a single resource (versioning, aliases)
• URI opacity (assuming a specific resource representation)
• Available representations (XML namespaces as really bad example)
• Hypertext links (resource representations should be good Web citizens)
• Orthogonality (identification, interaction, and representation are orthogonal)

• Loose coupling vs. tight coupling
• fewer requirements for cooperation mean fewer potential sources of problems
• taking independent developments into consideration (graceful degradation)
• Parsimony may conflict with optimization
• a fully backlinked Web would be a very different hypermedia system
• modifying resources would be expensive and require considerable efforts
• an uncontrolled Web allows failure and innovative development
• Programming Languages vs. Frameworks
• programming languages are very simple and very powerful
• frameworks are more complex and have some choices built into them
• both can be used to build good systems
• framework applications are more likely to not do really innovative things

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare, The Emperor's Old Clothes, 1980 Turing Award Lecture

• Web: URI + HTTP + HTML ( + XML)
• OASIS: Six SOA simplification committees for about 60 WS-* specs

• Web architecture is an additional set of constraints
• it is not a very complicated set of constraints
• but it still makes life more complicated than in an unconstrained world
• it may require a major redesign of an application
• Technology providers sometimes ignore Web architecture
• multimedia presentation concepts are often disconnected from the Web
• hypermedia researchers often regard the Web as inferior (or not as hypermedia at all)
• questions of client capabilities are often ignored (or brushed aside using statistics)
• Integration vs. Transport
• integrating into the Web requires application to conform to Web architecture
• sitting on top of the Web just requires to use HTTP for data transfer
• many Web Technologies are not integrated into the Web
• many Web Applications are not integrated into the Web

• Everything should be identified in a uniform way
• Identification and access methods evolve over time
• sms: and callto: did not exist when the Web was created
• Identification and access support evolve over time
• tel: now can be supported by an increasing number of clients
• The Web is one huge proof for the power of network effects
• it also is a lesson for many who did not take it seriously and failed

• Many URI schemes are named after protocols
• http: can be accessed using the Hypertext Transfer Protocol (HTTP)
• ftp: can be accessed using the File Transfer Protocol (FTP)
• mailto: sends electronic mail using the Simple Mail Transfer Protocol (SMTP)
• Some URI schemes do not really imply a protocol
• mailto: sends electronic mail using the Simple Mail Transfer Protocol (SMTP)
• mailto: may use any other appropriate technology for sending email
• instead of using protocols directly, they can be accessed indirectly through services
• Some URI schemes have no protocol for dereferencing resources
• urn: URIs are abstract names from some namespace
• urn:ietf:rfc:2648 identifies an IETF standard and not some specific copy
• geo:27.988056,86.925278 identifies a physical resource (accessing it is really hard)

• Agreement on the interpretation of resource representations
• HTML was the first standardized data format on the Web
• CSS and XML have become successful formats as well
• Some data formats are de-facto standards as Web formats
• GIF and JPEG for images and PNG as the successor of GIF
• Some formats are less integrated but still widely used
• PDF for paginated documents
• Some formats have become replacements for missing standards
• Flash for audio and video because no single format was sufficiently successful
• Some formats were intended to become standards but failed
• SVG for vector graphics
• SMIL for multimedia presentations

• Some things on the Web can be inconsistent
• guaranteeing consistency by design can lead to tight coupling
• well-defined ways of handling inconsistencies are better scalable
• Some things on the Web are not perfect
• technologies being used in ways not anticipated (XML, XML Namespaces)
• company goals vs. the greater good (browser war)
• The ideal Web vs. the real Web
• dealing with a given landscape can introduce additional constraints
• handling these constraints should not violate the general principles

• Design for openness and extensibility is a key factor
• design for and support evolution and extension and reuse
• try to be a good Web citizen by embracing integration
• Design with the Web in mind
• use Web standards where appropriate (URIs for identification)
• even intranet applications typically evolve and should be designed for the Web
• Make content visible, accessible, usable, reusable
• URI design guidelines should be defined and followed
• think about aggregation and granularity and access to resources
• use well-defined and well-documented XML for B2B scenarios
• reuse existing vocabularies or vocabulary parts whenever possible

• Principles (violating these causes architectural problems)
• Constraints (disregarding these causes technical problems)
• Good Practices (ignoring these causes user problems)

2008-09-04 Timeline Internet Architecture The Internet is the technical infrastructure on top of which the Web is built. Some of the services provided by the Internet are essential for the Web, most importantly the naming service and the data transfer service. The Domain Name System (DNS) provides the human-readable names for computers, which can then be used in the addresses of Web servers and ultimately Web pages. The Transmission Control Protocol (TCP) provides the reliable data transfer service between Web Servers and Web Browsers, building on the very robust Internet Protocol (IP).

• First regarded as a convenient workaround for floppy disks
• real computer scientists write compilers
• the value of computer networks depends on their size
• Early networking solutions were vendor-specific islands
• DECnet for Digital Equipment Corporation (DEC) customers
• XNS for Xerox customers
• SNA for IBM customers
• transmitting data between these networks was very cumbersome
• Bridging networks transparently became increasingly important
• more computers and networks increase the benefit of interconnections
• layering being used for internetworks, not only for networks

• Specific networks use specific abstractions
• how to address nodes (computers, phones, PDAs, RFID tags)
• how to address applications on these nodes
• how to transmit data to these applications
• Internetworks provide a network-independent abstraction
• nodes are addressed uniformly (IP addresses)
• applications are identified uniformly (ports)
• data transmission uses one set of protocols (TCP/UDP)

• Global network emerges by the end of the 80's
• some kind of internetworking protocols were required
• ARPANET had been running since the late 60's (1965: Berkeley-MIT)
• ISO/OSI was a new specification
• the idea was to build something new
• Open Systems Interconnection (OSI) as a general model for open systems
• OSI was specified rather than developed and tested
• For some time, it was unclear what the global internetwork would be based on
• Internet protocols were already established and running
• OSI promised a fresh start with bigger is better protocols

• Very early start and a lot of experience
• pragmatic and evolutionary approach
• if it's not broken, don't fix it
• Standardization by independent technical experts
• avoids the designed by committee effect of consortiums
• conservative and concentrating on stability
• implementations are required to prove technical feasibility
• simplicity whenever possible

Be liberal in what you accept, and conservative in what you send.

Jon Postel, RFC 1122

Whenever possible, communications protocol operations should be defined to occur at the end-points of a communications system, or as close as possible to the resource being controlled.

J. Saltzer, D. Reed, D. Clark, End-to-end Arguments in System Design

• End-to-end data transfer (IP addresses)
• Hiding lower-level heterogeneity
• Connection-less (each packet routed individually)
• Unreliable (packets may be lost or duplicated)

• IP identifies nodes by an IP address
• IP addresses are globally unique (and can be geocoded)
• IP uses 4 bytes for addresses (e.g., 128.32.226.29)
• maximum number of addresses: 2³² = 4 billion
• IPv6 extends the address format to 16 bytes (2¹²⁸ addresses)
• IP address shortage led to the some trickery using IP addresses
• Dynamic Host Configuration Protocol (DHCP) is used to assign addresses on-demand
• Network Address Translation (NAT) uses one IP address for more than one device
• IP addresses are well-organized
• important for routing (i.e., sending packets to the target host)
• not ideally suited for mobile or ad-hoc networks

• Flow-controlled (avoiding congestion)
• Reliable (no data lost or duplicated)
• Connection-oriented
• Application addressing

• IP may drop or duplicate packets
• TCP adds serial numbers in data packets
• if problems are detected, TCP recovers automatically
• TCP avoids network congestion and system overload
• slow start avoid flooding receivers with data they cannot process
• fast retransmit for avoiding timeouts when losing data
• a sliding window for controlling the amount of outstanding packets

• IP addresses depend on network topology and organization
• reorganizing a network may change all IP addresses
• identifying important hosts should not be address-based
• Names are supposed to be more stable than addresses
• a name is an abstract identification of something
• names can be used to obtain more information
• Network services should use names instead of addresses
• before using the service, a mapping has to be performed
• the Domain Name System (DNS) is providing this service

• DNS has a bootstrap problem
• DNS provides a service and should thus be identified by a name
• for resolving names into addresses, the DNS service is required
• DNS configuration is part of basic Internet configuration
• Dynamic Host Configuration Protocol (DHCP) provides , netmask, gateway, and DNS server address
• DNS names are hierarchically structured
• ischool.berkeley.edu, edu is the Top-Level Domain (TLD)
• TLDs are either generic (gTLD) or country code (ccTLD)
• subdomains are federated (e.g., edu, us, uk, tv)

• Names are not unique and namespaces are finite
• name disputes arise which were irrelevant before the Web
• cybersquatting as a popular way to make money
• Names can be worth a lot of money
• business.com was sold for $7.5 million
• Name inflation can be used to generate money
• aero, biz, coop, info, jobs, mobi, museum, name, pro, travel
• starting 2009, user-defined top-level domains will go on sale
• Names can have political significance
• ccTLDs are assigned based on the UNO's idea of what a country is
• Names can have symbolic significance
• Catalonia managed to get a domain of its own (cat)

• Domain owners can organize the assignment of subdomains
• berkeley.edu is an U.S. educational institution
• ethz.ch is a Swiss university
• imperial.ac.uk is a British university
• uts.edu.au is an Australian university
• Special rules may apply (Germany does not assign car license plate names)
• Organizations may be countries or companies
• countries have national organizations for assigning names
• companies may create an internal multi-level namespace (www.ischool.berkeley.edu)

• DNS is used by virtually all Internet applications
• names are more stable than addresses
• E-mail has some dedicated features built into DNS
• special entries (MX records) identify the e-mail server for a domain
• fallback entries help dealing with failing e-mail servers
• most URIs are based on DNS names
• http://ischool.berkeley.edu/ identifies the access protocol and the host
• the browser first performs a DNS lookup
• a TCP connection is then established to the address returned by the DNS

• Transport protocol based on , just like
• very thin protocol, adds few features to IP
• provides application addressing
• UDP is unreliable and connection-less
• ideal for fast streaming media (delay is critical, lost packets are tolerable)
• acceptable for one-packet applications (lightweight and fast)
• not acceptable for reliable data transfer

• How to find an Internet host
• hosts are configured (manually or by using DHCP)
• there is no externally controlled registry of available hosts
• routing finds the network, but what about the host?
• the sender broadcasts a request with the
• if there is such a host, it responds with its physical address
• the sender can now send the IP packet to the physical address

• The Internet is a series of tubes! It's not a big truck!
• The Internet can use various underlying networks
• transmits data between Internet hosts
• provides reliable data transfer for applications
• allows to use names rather than addresses

• The Internet is a communications infrastructure
• The Web is an Internet-based distributed hypermedia system
• In theory, the Web could run on any network infrastructure
• The Web's core network technology is HTTP
• HTTP uses TCP and DNS for transmitting Web content

2008-09-09 Cool URIs Language Negotiation The Web assumes an underlying network infrastructure providing a reliable, connection-oriented, flow-controlled, end-to-end transport service. Based on such a network service (today provided by the Internet), the Web's transport protocol moves representations of resources identified by a Uniform Resource Identifier (URI) between Web servers and clients. The most important protocols for data transfer on the Web is the Hypertext Transfer Protocol (HTTP).

• Web servers do more than just deliver files
• They receive a request for acting on a resource
• this may be a simple file retrieval
• additional information is available from the request's header fields
• the request URI may contain additional query information
• the request may transmit complex data
• Processing can mean anything, it is transparent for the client
• the result of processing yields a resource representation

• The Web is centered around resources
• HTTP has been designed to manipulate resources
• HTTP provides methods for getting, putting, updating, and even deleting resources
• Resources are useful abstractions for interfaces
• instead of an API, interaction is built around manipulating resources
• does that sound familiar?
• Document exchanges as components of business models
• APIs change and bind closely, documents can better withstand change and bind loosely
• the whole Web is built around resources, not APIs
• is the principle behind this design

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

• URIs in their general case are very simple
• the scheme identifies how resources are identified
• the identification may be hierarchical or non-hierarchical
• Many URI schemes are hierarchical
• it is then possible to use relative URIs such as in a href="../"
• the slash character is not just a character, in URIs it has semantics

[…] the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.

Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, January 2005

• Query components specify additional information
• it is non-hierarchical information further identifying the resource
• in most cases, it can be regarded as input to the resource

The query component contains non-hierarchical data that, along with data in the path component […], serves to identify a resource within the scope of the URI's scheme and naming authority […].

Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, January 2005

• Processing URIs is not as trivial as it may seem
• escaping and normalization rules are non-trivial
• many implementations are broken
• complain about broken implementations
• URIs are not just strings
• URIs are strings with a considerable set of rules attached to them
• implementing all these rules is non-trivial
• implementing all these rules is crucial
• application development environments provide functions for URI handling

• URIs identify resources
• abstractions which may not have physical representation
• Requesting a URI yields a resource representation
• should be an appropriate and useful manifestation of the abstraction
• Resources can have different representations
• in a well-designed environment, you should get what works best for you
• HTML for big screens vs. HTML for mobile devices
• an event calendar based on my location and preferences

provided by CacheLogic Inc.

The two basic protocols which every Web browser must implement are DNS access and HTTP. However, most operating systems provide an API for DNS access, so the browser can use this service locally and only has to implement HTTP. TCP (which is required as the foundation for HTTP) is usually provided by the operating system.

• HTTP needs a reliable connection
• the foundation for HTTP is the
• DNS resolution yields an IP address
• open TCP connection to port 80 or port specified in URI (http://rosetta.sims.berkeley.edu:8085/)
• HTTP is a text-based protocol
• the connection is used to transmit text messages
• all HTTP messages are human-readable (not all entities, though)
• basic HTTP operations can be carried out by hand

start-line
message-header *

message-body ?

• Header fields contain information about the message
• general header: Date as the message origination date
• request header: Accept-Language indicated language preferences
• response header: Server contains system information
• entity header: Content-Type specifies the media type of the entity
• HTTP defines a number of header fields
• unknown fields must be ignored (extensibility)
• unstandardized fields should use a X- prefix
• HTTP is about acting on these fields
• HTTP defines what HTTP implementations must or should do

• After opening a connection, the client sends a request
• the method indicates the action to be performed on the resource
• HTTP's most interesting methods are: GET, HEAD, POST
• other interesting methods are: PUT, DELETE
• The URI identifies the resource to which the request should be applied
• absolute URIs are required when contacting
• absolute paths are required when contacting a server directly
• the URI may contain
• fragment identifiers are not sent (they are interpreted on the client side)
• The Host header field must be included in every request

Method Request-URI HTTP/Major.Minor
[Header]*

[Entity]?

• Retrieval action based on the URI
• maybe implemented by reading a file
• maybe implemented by processing a file (PHP)
• maybe implemented by invoking a process
• Semantics may change based on header fields
• If-*: only reply with the entity if necessary
• Range: only reply with the requested part of the entity
• Cacheability depends on header fields of the response

GET / HTTP/1.1
Host: ischool.berkeley.edu

• The server's response to interpreting a request
• the status code is given numerically and as text
• 2** for variations of ok
• 3** for redirections
• 4** are different client side problems (404: not found)
• 5** are different server side problems
• Header fields specify additional information
• information about the server
• information about the entity (media type, encoding, language)

HTTP/Major.Minor Status-Code Text
[Header]*

[Entity]?

• HTTP/1.0 allowed one transaction per connection
• TCP connection setup and teardown are expensive
• TCP's slow start slows down the initial phase of data transfer
• typical Web pages use between 10-20 resources (HTML + images)
• typically, these resources are stored on the same server
• HTTP/1.1 introduces persistent connections
• the TCP connection stays open for some time (10 sec is a popular choice)
• additional requests to the same server use the same TCP connection
• HTTP/1.1 introduces pipelined connections
• instead of waiting for a response, requests can be queued
• the server responds as fast as possible
• the order may not be changed (there is no sequence number)

• Negotiation between two HTTP peers
• resources may be available in different representations
• possible dimensions are language, graphics format, character encoding, …
• using one URI, it should be possible to get the best resource
• Negotiation requires knowledge about the resource user
• languages depend on humans reading pages
• graphics formats depend on the browser's functionality
• Content negotiation is a form of a Web-based service
• client request a URI and have some constraints
• using these constraints, the best representation should be served
• ideally, content negotiation should not be too expensive

• Server Side Content Negotiation
• the server has a set of representations and information from the request
• the server returns the best representation based on the request
• Client Side Content Negotiation
• the server responds with a list of different representations
• the client (browser or user) makes a choice and sends a second request
• Transparent Content Negotiation
• Caches act as in client side negotiation and thus know the available representations
• Clients contacting the cache can be served by the cache as in server side negotiation

• Clients usually tell something about themselves
• Accept, Accept-Charset, Accept-Encoding, Accept-Language
• the server also knows their IP address
• the server may also use additional information (s)
• The server needs to find the best representation
• most easily by matching the request with available representations
• could also be implemented more dynamically by generating new representations

• HTTP often is end-to-end
• there is a direct connection between my browser and the server
• HTTP allows using proxies, which are HTTP intermediaries
• Proxies are used for security reasons
• a proxy is an important part of a firewall
• it hides the user's identity by acting on behalf of the user
• proxies are ideally suited for logging and filtering
• Proxies are used for performance reasons
• requests and responses can be cached, speeding up responses significantly
• caching depends on the ability to know when the cache is outdated
• HTTP enables proxies to validate their cached copies

A proxy is configured in the browser (manually or automatically), so that the browser sends all requests to the proxy instead of the target Web server. The proxy then forwards the request. Proxies can be chained, so that the requests and responses travel through a number of HTTP systems.

• Firewalls are used to protect computers
• protecting users from worms and viruses
• protecting servers from intrusion attacks
• firewalls analyze and block traffic based on complex rules
• A reverse proxy can be part of a firewall concept
• it is configured and maintained by the service provider
• it is a single access point through which HTTP traffic goes
• it is good because it bundles access control to servers behind it
• it is bad because it is a single point of failure

• HTTP is much more than file transfer
• it is a protocol for the concept of resource manipulation
• it is a distinct step away from the API approach to building distributed systems
• HTTP servers can be configured to deliver good or bad service
• this is a question of how well they are configured on the HTTP level
• it is also a question of how good the Web design is
• both issues together are required to set up a good Web server

2008-09-11 TLS · Code Book TCP and thus HTTP are clear-text protocols, which make no attempt to hide the data being transmitted. For secure data transfers, it thus is necessary to use additional technologies for providing secure data transfers. This lecture looks briefly into the foundations of cryptographic primitives (such as one-way functions and encryption) and cryptographic protocols. For the Web, the most interesting security feature are secure HTTP interactions, which are provided by HTTP over SSL (HTTPS), a protocol that layers an encryption layer (SSL or TLS) between TCP and HTTP. Assignment 1 : HTTP Content Negotiation

• Cryptography is structured into different layers
• layering is a well-established principle for separation of concerns
• Cryptographic primitives implement very basic functionality
• changes and advancements in this area are limited to very specialized researchers
• it is easy to make fatal mistakes which then challenge everything built on top if it
• Cryptographic protocols assemble primitives into application-level solutions
• primitives solve very basic security problems (fingerprints, encryption, …)
• protocols combine these into applications (digital signatures, secure communications, …)

• Hashes (or message digests) are a well-known principle in computer science
• fast to compute (the goal is to make data handling more efficient)
• few collisions (there are always collisions because of the smaller size)
• checksums and Cyclic Redundancy Check (CRC) are popular hashes
• One-way functions are cryptographically safe hashes
• not just for detecting errors, but also for preventing tampering
• often referred to as cryptographic hash or digital fingerprint
• One-way functions must satisfy additional criteria
• it must be very hard to find an input producing a given output
• it must be very hard to find two inputs producing the same output (collision)

• Secret-Key is was most people think of when thing of encryption
• symmetric cryptography is another popular term
• One key for encryption and decryption
• Losing the key makes encrypted data openly readable
• there must be a secure channel to transport keys
• Good for long-term relationships with few partners
• exchange secret keys as part of the initial setup of a relationships
• adding partners requires a secure channel for key exchange
• changing keys requires a secure channel for key exchange
• Almost impractical in an environment with many ad-hoc partners

• Public-Key intuitively is hard to accept as a concept
• asymmetric cryptography is another popular term
• Key pairs of one public and one secret key
• key generation is the process of generating these key pairs
• The public key can be made available to the public
• only the secret key can do the inverse operation of the public key
• Good for short-term relationships with many partners
• publish your public key so that it can be used worldwide
• everybody can encrypt data using the public key
• only the owner of the secret can can decrypt the message and read it
• Computationally expensive and not good for a large amounts of data

• Cryptographic primitives in most cases are not sufficient
• they provide basic functionality for fundamental tasks
• they must by combined to provide solutions for real-world problems
• Typical problem #1: How to ensure key authenticity
• with insecure keys, the majority of cryptographic methods is worthless
• Typical problem #2: How to communicate securely without shared keys
• many interesting scenarios are based on ad-hoc interactions
• secret-key does not work, public-key needs to verify the peer
• Typical problem #3: How to check authenticity and integrity of data
• integrity can be done with checksums, but these could be forged
• authenticity needs a cryptographically secure way of combining identity and data

• Hashes are used to check data integrity
• s are used to check data integrity securely
• it is not possible to reverse engineer data for a given hash
• Signed hashes can be used to ensure data authenticity
• if the hash sum is signed, it cannot be changed
• if the data is changed, its hash will not match the signed hash
• Digital signatures work as long as the hash can be securely signed
• there must be a trusted public key for checking the hash signature

• Certificates are digital signatures issued by a trusted party
• most digital signatures are created with certified public keys
• this means the digital signature is created based on a digitally signed key
• Who can you trust on the Web?
• trust can only start to grow based on initial trust in something
• many systems come with pre-installed trust (root certificates)
• certificates from other issuers will cause browsers to complain
• Certificates (like domain names) are a very easy way to make money
• in theory there are different levels of certificates with different levels of identity checking
• in practice most sites choose the cheapest one that does not give an error message

• Public-Key cryptography is computationally expensive
• it is possible to encrypt all traffic using asymmetric key pairs
• this generates considerably more load on the server side
• Combining public- and secret-key cryptography
1. check the public key for authenticity (using a )
2. generate a key for a secret-key encryption scheme
3. use the public key to securely transmit the secret key
4. use the secret key for securely transmitting the payload
• Combines the advantages of both methods
• the lower complexity of secret-key algorithms
• the ability of public-key algorithms to work without a secure channel

• HTTP sends clear-text messages
• listening to HTTP traffic is trivial
• information transferred via simple HTTP is public
• many Web data transfers (in most cases form data) should be secure
• Making HTTP secure requires additional mechanisms
• S-HTTP was an attempt to define a secure version of HTTP
• HTTPS uses a secure communication layer underneath HTTP
• Encryption is done by a layer on top of TCP
• Secure Sockets Layer (SSL) is the protocol layer invented by Netscape
• Transport Layer Security (TLS) is the standardized Internet version
• TLS adds more encryption schemes and more flexibility
• Lower-level methods may also provide encryption
• Virtual Private Networks (VPN) provide IP-based encryption
• WEP and WPA provide network interface encryption
• IP-based encryption is not end-to-end in the sense of application-to-application

• Securing HTTP can be done in two ways
1. using a secure communications infrastructure
2. making the protocol itself secure (adding cryptographic features)
• Secure infrastructures are better in terms of layering
• they can be reused for other applications (email, file transfer, …)
• they can be evolved independently from the application layer
• Secure protocols can provide better integration of security features
• signed interactions which can be archived for later retrieval
• Layering is more important than tightly integrated security

• Certificates are used to guarantee a party's authenticity
• Certificates are digital signatures issued by trusted parties
• One authenticated, public keys can be used to securely communicate
• For efficiency reasons, payload encryption uses secret-key cryptography
• Encryption on the Web is based on HTTPS
• VPN-based encryption can be used to secure all traffic

2008-09-16 HTTP Authentication Spec For any task involving personalization and/or trust, it is not only necessary to have a concept for providing privacy, but also to have concepts for identity and how to prove identity, which needs authentication. HTTP has built-in mechanisms for authentication, and the standard HTTP Authentication mechanisms are Basic Authentication and Digest Access Authentication. Instead of these mechanisms, many applications implement their own ways of authentication, which often are based around authentication using HTML Forms.

• What can you be certain of when using HTTPS?
• in most cases there only is a server side
• if attackers can manipulate your DNS they can attack HTTPS
• Many scenarios require reliable identification of the client
• HTTPS supports client side certificates for identifying clients
• rarely used outside of closed user groups
• Traditional user identification against a trusted server
• trusted servers can be used for securely transmitting authentication credentials
• identity and authentication methods are handled on a per-server basis
• when using many services, users end up with many identities

• Usernames represent identities
• whoever uses the name is identical with the user
• giving away the username means giving away the identity
• Passwords are used to authenticate a user
• identities are secured and checked by using password
• giving away the password means giving away the authenticity
• Usernames and passwords must be handled securely
• transmitting them in clear text (such as HTTP) is a very bad idea
• reusing username/password pairs is a risky practice

• HTTP servers can deny access because of access control
• 401 Unauthorized means the resource is access controlled
• 403 Forbidden means the resource is inaccessible
• 405 Method Not Allowed signals a request using the wrong request method
• Two different approaches to unauthorized access are possible
• repeat the HTTP request with the proper authentication credentials
• redirect to a and establish an authenticated

• Authentication is based on authentication realms
• a set of resources for which the authentication is required
• an opaque name which is used to signal which login is required
• username/password probably is specific for a given realm
• Users supply username and password through the client
• sent as Base64 encoded username:password string
• username and password are not transmitted securely
• basic authentication should always use HTTPS
• Authorization is handled on the server side

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="SokEvo"

GET /private/index.html HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Clients typically access more than one protected resource
• a perfectly stateless client would always request authentication from the user
• using the clients can identify repeated accesses
• Clients remember the authentication and replay it automatically
• browsers provide little control over this feature
• logging out of HTTP authenticated sessions is hard

• is a serious security problem
• username and password are transmitted unencrypted
• Digest Access Authentication does not require transmission of the password
• only information computed using a is transmitted via HTTP
• server-side needs clear-text password to compute HTTP header values
• Three-step one-way function calculation of response value
1. HA1 = MD5(username, realm, password)
2. HA2 = MD5(HTTP method, request URI)
3. Response = MD5(HA1, nonce, nc, cnonce, qop, HA2)
• Server responses may include AuthenticationInfo
• information for the next authenticated request

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="testrealm@host.com",
	qop="auth,auth-int",
	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
	opaque="5ccc069c403ebaf9f0171e9517f40e41"

GET /dir/index.html HTTP/1.0
Authorization: Digest username="Mufasa",
	realm="testrealm@host.com",
	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
	uri="/dir/index.html",
	qop=auth,
	nc=00000001,
	cnonce="0a4f113b",
	response="6629fae49393a05397450978507c4ef1",
	opaque="5ccc069c403ebaf9f0171e9517f40e41"

• works with browser controls (including window)
• no possibility to log out without using browser-specific controls
• client side security depends on browser security measures
• Using gives more freedom in session management
• authentication and authorization are completely application-based
• if there were secure personal browsers this would not work very well

• HTTP is used inconsistently with form-based login
• some frameworks use redirections to login pages and then to resources
• some frameworks use login pages as front ends to protected resources
• HTTP messages never indicate any kind of authentication problem
• 302 Found is being sent for unauthenticated access (Location login page)
• successful login redirects to the original resource
• 401 Unauthorized signals missing authorization (no WWW-Authenticate)
• Use HTTP to display login pages
• 403 Forbidden when requesting a protected page without credentials
• send the login page as the HTML in the response
• after authentication and authorization serve the same page as 200 OK
• The login representation is the preferred method

• uses standards and standard mechanisms
• should always use HTTPS
• can be safely used over unencrypted connections
• uses fewer Web methods
• some frameworks use login representations for protected resources
• some frameworks use redirects to channel requests through a login page

2008-09-18 Wikipedia State · Cookies Spec HTTP is a stateless protocol, where each request/response interaction is a separate interaction and there is no protocol support for longer sessions (such as a user logging in and working on a Web site as an identified user). State management refers to mechanisms which provide support for this kind of scenario, the most popular choice for state management are cookies. Another possibility is URI-based state management. This lecture is a first glimpse into the world of Representational State Transfer (REST), the Web's fundamental model of handling interaction with resources.

• HTTP has no session concept
• interactions are HTTP request/response pairs and not site visits
• HTTP/1.1 does not change this, it is only a performance optimization
• servers can not reliably identify users interacting with a Web site
• Sessions should not be used to track resource state
• the semantics of resource interactions should not depend on client state
• application behavior can depend on client state
• HTTP's concept of stateless interaction is important
• the Web's idea is to use loose coupling between clients and servers/resources
• retrofitting the Web with tight coupling through server state is bad design

• Sessions should be maintained on the client
• the client has all relevant information about a session
• when the server restarts, no information will be lost
• if something has to be persistent, it should be a resource
• Small and short-term solutions may work well with server state
• scaling these solutions typically introduces many problems
• debugging can be hard because the state is transient
• integration with other clients can become a difficult problem
• Three ways of client-side state are possible
1. sending back and forth state as part of the interaction
2. store state in the server and refer to it from the client (not recommended)
3. store state at a URI and use the URI to refer to that state

• Typical session scenarios can be mapped to resources
• Client: Show me your products
• Server: Here's a list of all the products
• Client: I'd like to buy 1 of http://ex.org/product/X, I am "John"/"Password"
• Server: I've added 1 of http://ex.org/product/X to http://ex.org/users/john/basket
• Client: I'd like to buy 1 of http://ex.org/product/Y, I am "John"/"Password"
• Server: I've added 1 of http://ex.org/product/Y to http://ex.org/users/john/basket
• Client: I don't want http://ex.org/product/X, remove it, I am "John"/"Password"
• Server: I've removed http://ex.org/product/X to http://ex.org/users/john/basket
• Client: Okay I'm done, username/password is "John"/"Password"
• Server: Here is the total cost of the items in http://ex.org/users/john/basket
• This is more than just renaming session to resource
• all relevant data is stored persistently on the server
• the shopping cart's URI can be used by other services for working with its contents
• instead of hiding the cart in the session, it is exposed as a resource

• Invented as a way to compensate for HTTP's lack of state
• application state is being sent to the client (SetCookie2)
• the client transmits application state in requests (Cookie)
• Cookies do not contain code that is executed
• some data that represents application state (by value or by reference)
• this data is stored by the client and returned to the server
• the client is not supposed to interpret the data in any way
• Cookies can be used in many different ways
• when used for tracking application state they are unproblematic
• when used for tracking resource state they introduce problems
• Cookies tightly bind clients to opaque concepts on the server

• Big ad servers are digital hubs in the commercial Web
• consumers switch content providers but get the same ad provider
• tracking consumers across content providers is very valuable
• Cookies set by ad providers are sent very frequently
• each site that uses the ad provider triggers the cookies to be sent
• detailed profiling can be employed for creating consumer profiles
• Content and ad providers can cooperate for better profiling
• consumers log in to content providers are are reliably identified
• their personal profile can be matched with the ad provider's profile
• ad provider consolidation makes this scenario realistic

Typical Web resources (HTML pages) are assembled from a number of resources retrieved by HTTP. Any resource not originating on the server that is hosting the HTML page is considered a third-party resource. If the HTTP response for such a resource contains a cookie, it is a third-party cookie.

• Authentication can be tracked with
• this is possible because authentication is built into HTTP
• Other session concepts are not supported by HTTP
• cookies have become the generic solution for all session tracking
• Cookies are increasingly limited by browsers
• cookies have gained some notoriety as privacy invaders
• browsers have more restrictive default settings
• an increasing number of users restricts cookie support
• Session-oriented Web sites often depend on cookies

• s are a piece of information stored on the client
• they are sent by the server as a result of a request
• they are returned by the browser in a response to the same site
• The same information can also be encoded in the URI
• normally a response contains a cookie and an HTML page
• the same effect is achieved when all links include the cookie value
• this method often results in very long URIs
• Some Web application frameworks switch automatically
• J2EE checks for cookie support and switches to URI rewriting if required
• Problems with bookmarks and caches

• s transmit session information via HTTP
• encodes session information in URIs
• are a way to send data to a server
• in most cases this is data that is entered by the user
• Hidden form fields can be used to send data that is part of the HTML
• hidden form fields are never displayed to the user
• their predefined values are sent as part of the form submission
• Hidden form fields are essentially the same as
• they can only be used if the interaction is based on forms
• they also require the Web page to be dynamically generated for each request
• the values end up as URI query string or request entity

• Sessions should only be used for application state
• Cookies are the best way to track sessions
• cookies should be self-contained rather than referential
• Alternative methods are URI rewriting and hidden form fields
• more robust than cookies but unpleasant side-effects

2008-09-23 REST vs. SOAP · What is REST? · REST Interfaces RESTwiki Representational State Transfer (REST) is an architectural style for building distributed systems. The Web is an example for such a system. REST-style applications can be built using a wide variety of technologies. REST's main principles are those of resource-oriented states and functionalities, the idea of a unique way of identifying resources, and the idea of how operations on these resources are defined in terms of a single protocol for interacting with resources. REST-oriented system design leads to systems which are open, scalable, extensible, and easy to understand.

• The Web is one distributed hypermedia system
• the main architectural components are URIs, HTTP, and HTML
• all other Web technologies are built on that foundation
• if they are not, they are very likely not well-designed Web technologies
• The Web is amazingly open, scalable, extensible, and easy to understand
• openness allows new technologies to be introduced
• scalability ensures that the system does not contain bottlenecks
• extensibility allows the Web to evolve without any redesign of existing parts
• simplicity makes sure that the system survives and evolves
• No other information system gets even close to the Web
• but not all information system designs can accept the Web's limitations
• REST should be seen as a guideline how to build a true Web application
• other applications will continue to be built using other approaches

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare, The Emperor's Old Clothes, 1980 Turing Award Lecture

• Object-Orientation is a Software Engineering Style
• it can be applied to any programming language
• depending on the language, this is more or less easy
• OO languages support or even enforce certain design patterns
• spaghetti code can be written in every programming language
• Implementations can always be bad or good
• the quality of the implementation depends on the programmer
• programmers can be better supported and controlled with an OO language
• implementation quality metrics must be based on the product, not the language
• Good programmers always produce good code
• Bad programmers always produce bad code
• Average programmers need good tools to produce good code

• Technologies help solving problems
• they are built with certain goals in mind
• they specialize in solving a problem in a specific way
• Technology choices are very important
• the technology (i.e., the tool) shapes the way how a problem is solved
• working against the tool is possible, but hard and rarely done
• Technologies sometimes cloud the more important issues
1. the problem must be well-defined and fully understood
2. the general approach to solve a problem must be identified
3. finally, a technology supporting this approach must be chosen

• Implementations are built on (and shaped by) technologies
• Implementation = Concepts + Technologies
• Implementation quality depends on both factors
• the right choice of technologies is very important
• the responsible use of that foundation is equally important
• Good REST is as hard to grasp as good OO
• products may claim that they are REST/OO
• they may even use technologies which support REST/OO
• only careful inspection reveals the truth of this claim
• in most cases, this only happens when the product needs to be changed

• Resources are defined by URIs
• Resources are manipulated through their representations
• Messages are self-descriptive and stateless
• There can be multiple representations for a resource
• Application state is driven by resource manipulations

• Resources are defined by URIs
• resources can never be accessed or manipulated directly
• REST works with resource representations
• Resources are all the things we want to work with
• if you cannot name something, you cannot do anything with it
• a popular resource type on the Web are documents
• documents usually are a structured collection of information
• Documents are abstract concepts of descriptive resources
• they may be used in different contexts (e.g., formats)
• different applications may be interested in different representations
• the underlying resource is always the same

• State is represented as part of the content being transferred
• server interruptions do not create problems for the client
• it is possible to switch between servers for different interactions
• clients can simply store the representation to save the state
• State transfer makes the system scalable
• data transfer is not state-specific (no stateful connection handling)
• state is transferred between client and server

• Distributed systems must be based on a shared model
• traditional systems must agree on a common API
• REST systems structure agreement into three areas
• REST is built around the idea of simplifying agreement
• nouns are required to name the resources that can be talked about
• verbs are the operations that can be applied to named resources
• content types define which information representations are available

• Nouns are the names of resources
• in most designs, these names will be URIs
• URI design is a very important part of a REST-based system design
• Everything of interest should be named
• by supporting well-designed names, applications can talk about named things
• new operations and representations can be introduced
• Separating nouns from verbs and representations improves extensibility
• applications might still work with resources without being able to process them
• introducing new operations on the Web does not break the Web
• introducing new content types on the Web does not break the Web

• Operations which can be applied to resources
• The core idea of REST is to use universal verbs only
• universal verbs can be applied to all nouns
• For most applications, HTTP's basic methods are sufficient
• GET: Fetching a resource (there must be no side-effects)
• PUT: Transfers a resource to a server (overwriting if there already is one)
• POST: Adds to an existing resource on the server
• DELETE: Discards a resource (its name cannot be used anymore)
• Corresponding to the most popular basic database operations
• CRUD: Create, Read, Update, Delete

• POST adds instead of an overwriting update
• POST can have different effects
• by POSTing, state is changed and a new resource is created
• by POSTing, only the existing resource is changed
• the server signals the difference using HTTP responses (200 OK or 201 Created)
• This is a design choice
• if the added information needs to be accessible individually, create a new resource
• for changes of an existing resource, no new resource has to be created
• Make sure that resources are navigable using URIs
• if appropriate, a relationship can be represented in the resource format

• Representations should be machine-processable
• they don't have to, they may be opaque to applications
• in many cases, machine-processable representations are advantageous
• Resources are abstractions, REST passes representations around
• resources can have various representations (i.e., content types)
• clients can request content types they are interested in
• Adding or changing content types does not change the system architecture
• different clients and servers support different content types
• allows content types to be negotiated dynamically

• REST is a description of the Web's design principles
• it is not something new, it is simply a systematic view of the Web
• REST's claim is to be able to learn from the Web's success
• Web Services (the SOAP flavor) do not build on REST
• they use HTTP as a transport protocol
• they re-create Web functionality through additional specifications (WS-*)
• they have been built by programmers using a top-down approach
• REST and Web Services have different design approaches
• REST starts at the resources and takes everything from there
• Web Services focus on messages, which in most cases are operations

• REST is not tied to a particular set of technologies
• are the most common choice for nouns
• methods are the most common choice for verbs
• is the most common choice for content types
• Choosing other technologies should have a very good reason
• building a REST system should make it open and accessible
• technology choices are as important as architectural choices

• REST requires a lot of URI design
• instead of being generated as a side-effect, they are the core of the system
• Designing URIs and starting from them is a new way of thinking
• URIs are much more powerful than just being an address of a Web page
• URIs are names for concepts
• concepts are never transmitted, only their representation
• having to focus on concepts rather than representations is helpful

• HTTP is the most successful RESTful protocol
• HTTP's author Roy Fielding coined the term REST in his Ph.D. thesis
• HTTP should be regarded as an application-level protocol
• Web Service technologies use HTTP as a transport protocol
• HTTP has much more to offer than a firewall-penetrating pipe
• Web infrastructure is built around proper HTTP usage
• caching is built into HTTP and caches optimize the Web transparently
• authentication can be done using HTTP's authentication methods
• secure data transfer can be done using

• URI-identified resources are abstract concepts
• for machine-based processing, XML is a good representation
• for human-oriented interactions, HTML probably is a better choice
• Connections to other resources must be done by URI
• XML does not make built-in assumptions about identifiers
• but it does support URIs, for example with XInclude and XML Base
• RESTful applications are about navigating a Web of URI-identified resources

• REST is an architectural style
• URI/HTTP/HTML/XML may be replaced
• the general principle of resource-based interaction remains valid
• RESTful system designs can create better systems
• a little bit more design effort in the beginning
• a lot less headaches later
• SOA often are not really RESTful
• SOA often focuses on operations
• REST focuses on resources
• RESTful design is a good starting point for OO implementations

2008-09-25 Unicode · History Every character-based document is based on some model of which characters are available, and how they are encoded. Unicode is the most popular character set today and provides a variety of encoding schemes, each of them being a Unicode Transformation Format (UTF). In addition to character sets and encodings, other issues relevant when dealing with characters are transcoding and normalization, which deal with the problems arising when using different character encodings or different encodings of particular characters.

• American Standard Code for Information Interchange (ASCII)
• for the first time a basic set of characters had a universally accepted encoding
• many Internet protocols (such as HTTP) encode their information in ASCII commands
• ASCII is a very limited repertoire of characters
• basic ASCII contains 128 characters (7 bit) with a number of control chars
• no variants of characters (german umlauts, french accents) are supported
• various code pages extending ASCII to 8 bit exist and are hard to distinguish
• Character is not a trivial concept when regarded globally
• european languages all have writing systems based on a small number of atoms
• other languages and writing systems have vastly different ideas of language atoms

Character. (1) The smallest component of written language that has semantic value; refers to the abstract meaning and/or shape […]

The Unicode Standard, Version 4.0, Addison-Wesley, 2003

• The alphabetic approach is only one of several possibilities
• A character in Japanese hiragana and katakana scripts corresponds to a syllable (usually a combination of consonant plus vowel)
• Korean Hangul combines symbols for individual sounds of the language into square blocks, each of which represents a syllable; depending on the user and the application, either the individual symbols or the syllabic clusters can be considered to be characters
• In Indic scripts each consonant letter carries an inherent vowel that is eliminated or replaced using semi-regular or irregular ways to combine consonants and vowels into clusters; depending on the user and the application, either individual consonants or vowels, or the consonant or consonant-vowel clusters can be perceived as characters
• Arabic and Hebrew vowel sounds are typically not written at all; when they are written they are indicated by the use of combining marks placed above and below the consonantal letters

[A Glyph is] a recognizable abstract graphic symbol which is independent of a specific design.

ISO/IEC 9541:1991, Information Technology – Font Information Interchange

• Visual rendering introduces the notion of a glyph.
• There is not a one-to-one correspondence between characters and glyphs
• A single character can be represented by multiple glyphs (each glyph is then part of the representation of that character); these glyphs may be physically separated from one another
• A single glyph may represent a sequence of characters (this is the case with ligatures, among others)
• A character may be rendered with very different glyphs depending on the context
• A single glyph may represent different characters (e.g. capital Latin A, capital Greek A and capital Cyrillic A)

• Text documents need ways to represent characters
• computers handle bits, not characters
• to handle characters, computers need a mapping from characters to bits
• For a long time, computers were doing their work in a very isolated way
• I think there is a world market for maybe five computers. (¬ T. J. Watson)
• With more computers being used, more data is exchanged between computers
• Data rot happens on all levels (media, formats, applications)
• Standardization of character sets started in the 60's
• ASCII was the first generally accepted character set
• EBCDIC was invented and marketed by IBM (and a terribly designed character encoding)
• ISO 8859 was the first attempt to better support character sets beyond ASCII
• asian scripts were always a problem because of the number of characters they need

EBCDIC (1964)

Augmented EBCDIC

• ASCII is called ASCII for a reason
• it works well for english-speaking countries
• the majority of other languages cannot be represented
• Character sets and the 8 bit computer start to collide
• ASCII is very convenient because characters and bytes correspond 1:1
• every character set expanding ASCII will make this more complicated
• complications can occur within and/or outside of the character set
• Introducing a character set beyond 8 bit is a fundamental change
• dealing with and counting bytes is a seductively simple idea
• Introducing several 8 bit character sets saves the 8 bit world
• by introducing several character sets, each of them can remain 8 bit
• the complexity has now been shifted to the handling of various character sets

• A family of character sets rather that a single character set
• each ISO 8859 family member is an 8 bit character set (256 characters)
• the lower half (128 characters) are always the same (ASCII)
• the upper half is supporting different user groups and changes between versions
• ISO 8859 files cannot be identified by inspection
• ASCII characters can always be safely interpreted (identical on all ISO 8859 code pages)
• the upper half can only be interpreted if the code page is well-known
• ISO 8859 environments must carefully track the code pages being used
• failure to do so results in misinterpretation of characters