Industry Standards

1
Industry Standards
2
Review

• Whats the difference between a web server, a web
  site, and a web service?
• Whats can you do with a WSDL file?

3
Learning Objectives

• Understanding standards documents
• Terminology
• Conventions
• Understanding what gets standardized and what
  doesnt
• Understand extension mechanisms
• Understand definition and adoption process
• Analyze stakeholder interests and strategies

4
Purpose of Technical Standards

• Product Interoperability

Eudora Client
Eudora Client
IMAP protocol
IMAP Server
Mulberry Client
Mulberry Client
IMAP protocol
PINE Client
5
Review System Architecture

• Components
• The parts that interact to make the system
• Functions
• What the components do
• Interfaces
• How the components interact

6
What Gets Standardized

• How things work/work together
• Functions assigned to components
• Interfaces between components
• For example,
• Protocols for order of data (message) exchange
• Data (message) formats
• Principle standardize as much as necessary, and
  no more
• Standardizing too much limits innovation

7
TerminologyMay, Should, Must, Must Not

• Required features (MUST)
• If interacting with a compliant product, assume
  it implements required feature
• Do implement in your compliant product
• Suggested features (SHOULD)
• Dont assume other compliant products will
  implement
• Do implement it in your compliant product
• Allowed features (MAY)
• Assume other compliant products might implement
• Up to you whether to implement in your compliant
  product
• Forbidden features (MUST NOT)
• Opposite of required

8
The IMAP Protocol

• General format (C client S server)
• C ltid taggt ltcommandgt ltargumentgt
• S ltid taggt ltresponsegt
• The id tag is generated by the client
• Its typically a short alphanumeric, e.g., A001
• Client can send multiple requests before
  receiving answer to first one
• Id tag helps pair response with request, a
  sub-session mechanism

9
The IMAP Protocol

• Some commands
• LOGIN
• SELECT
• RENAME
• SEARCH
• FETCH
• Why no SEND command?
• Many commands apply to a specific message or
  messages
• The command arguments indicate the target
  message(s) using one of two IMAP identifiers

10
Message IDs

• IMAP UID
• 32-bits
• Assigned in ascending order within mailbox
  (folder)
• Local namespace of UIDs for each mailbox
• In another mailbox, UID may be reused
• MUST be preserved within session
• SHOULD be preserved between sessions
• Can be used by client to resynchronize with
  server following a temporary disconnect
• IMAP message sequence number
• Relative position of message in current mailbox
• If message deleted, remaining messages renumbered
• Note Email messages are associated with an SMTP
  message ID, but this is not used by IMAP

11
Sample Command LOGIN

• C a001 LOGIN SMITH SESAME
• S a001 OK LOGIN completed

12
Sample Command SEARCH

• C A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM
  "Smith"
• S SEARCH 2 84 882
• S A282 OK SEARCH completed

The server response includes the message sequence
number(s) of the matching message(s)
The indicates that this is status
information, not a completed command
13
Sample Command FETCH

• C A654 FETCH 24 (FLAGS BODYHEADER.FIELDS (DATE
  FROM))
• S 2 FETCH ....
• S 3 FETCH ....
• S 4 FETCH ....
• S A654 OK FETCH completed

14
Protocol State Diagrams

• Nodes (boxes, circles) represent states
• Directional links
• Each link out of a node indicates one possible
  action that can occur when the system is in that
  state
• Label on link indicates what the action is
• Endpoint of a link indicates the next state of
  the system after the action is completed
• Link can point back to originating node!
• I.e., stay in same state

15
IMAP State Diagram (Incomplete)

• In non-authenticated state, the client MUST
  supply authentication credentials before most
  commands will be permitted. This state is
  entered when a connection starts unless the
  connection has been pre-authenticated.
• - RFC2060 Sect. 3.1

Start state
OK
Non-authenticated
PREAUTH
LOGIN or AUTHENTICATE
authenticated
SELECT
CLOSE
selected
16
Whats Not Standardized in IMAP?

• Given the principle that we should standardize as
  much as necessary, but no more
• What decisions should be left to the implementer
  of an IMAP client?
• How to do sorting/searching on server
• How to display things on user side
• What else?

17
Building Standard-Compliant Software

• Standards documents are often long and complex
• Building a compliant implementation can be
  difficult
• Important to test compliance/compatibility

18
Compatibility Testing

• Reference implementation
• A known-good implementation of all
  entities/agents that can participate in the
  communication protocol.
• Syntax checkers
• Test the format of data files produced by an
  application
• Test suites
• Set of tests that executes important paths
  through the program, even paths that wouldnt be
  executed under normal conditions (e.g., error
  handling routines)

19
Standards and Innovation

• Paradox
• Standards limit innovation
• All compliant entities operate as dictated by the
  standard
• But they can also enable innovation
• Standards allow innovation on things that arent
  standardized
• Implement just the new features
• Open-closed principle for interfaces
• Extensions can be made to the interface
• You can add new interfaces as long as interfaces
  specified in the standard are implemented as
  required

20
Example IMAP Extension Mechanism

• Allows extra commands
• Commands beginning with X are non-standard
• If server knows how to respond, it does
• If not, it does nothing
• (Potential problem of duplicate use of Xnames)
• Allows server to say which extensions it handles
• C CAPABILITY
• S set of commands it knows how to handle

21
Where Else Have We Seen Extension Mechanisms in
this Course?

• Or where else could they be useful?

22
Summary

• Using IMAP as an example
• Understanding standards documents
• Terminology
• Conventions
• Understanding what gets standardized and what
  doesnt
• Understand extension mechanisms

23
Learning Objectives

• Understanding standards documents
• Terminology
• Conventions
• Understanding what gets standardized and what
  doesnt
• Understand extension mechanisms
• Understand definition and adoption process
• Analyze stakeholder interests and strategies

24
Midterm Results

• If I assigned grades today, based only on midterm
• But Ill probably be more generous right before
  vacation

25
Standardization Processes

• Usually negotiation among parties with stake in
  outcome
• Sometimes dictated by powerful entity
• Government
• Dominant company
• De facto standards
• First implement the protocol, then call it a
  standard (if everyone adopts)
• De jure standards
• First create the standard, then implement

26
Communications Standards Bodies

• ITU/CCITT (International Telecommunication Union)
• Dominated by telecom service providers
• For example, modem standards such as v.90
• ISO (International Organization for Standards)
• US Representative is ANSI (American National
  Standards Institute)
• Greater influence from equipment providers
• For example, the OSI model and CDR formats
• IETF (Internet Engineering Task Force)
• For example, HTTP, SMTP, IMAP, TCP, IP
• U.S. National Institute of Standards and
  Technology (was National Bureau of Standards)
• Government body
• W3C World Wide Web Consortium

27
IETF Working Groups

• Charter
• Narrow focus of work
• Specifies goals and milestones
• Mailing list and chairs
• Anyone can join (if you have time)
• Academics, industry, independents
• Rough Consensus and Running Code
• No formal voting
• Disputes resolved by discussion and demonstration

28
Standards Documents

• Internet Draft
• Easy to publish expires after 6 months not
  citable
• Requests For Comments (RFC)
• Several types/maturity levels
• Standards track
• Proposed Draft Standard
• Non-standards track
• Experimental Informational Historic
• Best Current Practices
• For standardizing practices
• RFC2026 on standards is an example

29
Proprietary and Open Standards

• Three dimensions of openness
• Public process of creation
• Freedom to use
• Public availability of full specification
• Licensing fees for proprietary technologies
  required to implement specification
• Ability to make changes

presnick Prospect of licensing fees for HDTV
made the standards process high stakes MIT Tech
article, 30M settlement from Dolby Labs
30
Adoption of Standards

• The nice thing about standards is that there are
  so many to choose from
• attributed to Grace Hopper, 1950s
• Widespread adoption is largely a self-fulfilling
  prophecy
• Governments sometimes influence adoption
• Purchasing power
• Regulatory power

31
The Economics of Networks

• Economy of scale
• Network externality (network effect)
• Value of a network technology increases the more
  people use the technology
• The fax machine is the classic example. The
  value of my owning a fax machine increases as the
  number of machines in use increases.
• Critical mass
• Positive feedback
• Winner-take-all
• Lock-in

32
Standards and Network Effects

• Compatibility merges networks
• Consider memory cards for cameras
• Without standards
• Each vendor sells integrated product
• Cameras and memory cards
• Customers of each vendor form a separate network
• Competition between networks
• With standards
• Dis-integrate products into components
• Mix and match from separate vendors
• One large network includes all customers
• Competition within network
• On components features that arent standardized

33
Stakeholder Interests

• Winners
• Vendors who can compete on one component, but not
  on the whole system
• For example, vendors of memory cards but not
  cameras
• For example, vendors of client software
  (browsers, IM clients, mail clients
• Vendors who gain licensing royalties from others
  implementation of the standard
• For example, Dolby Labs with HDTV standard
• Vendors whose technology sector is favored
• For example, hard disk vendors versus RAM vendors
• Losers
• Dominant vendors of integrated product who are
  dependent on network effects to lock customers in
• E.g., IBM in mainframes, MS in integrated
  OS/applications

34
Standards Strategies for Stakeholders

• Get everyone to adopt as a standard something
  that
• Youve already implemented
• Includes technology others will have to license
  from you
• Will create a large market for products where you
  have an advantage
• Try to block standardization (if you dont want
  interoperability)
• Dont participate
• Participate but drag your heels
• Embrace but add proprietary extensions, or dont
  implement fully or correctly

35
Trends Over Time

• Stovepipe ? shared infrastructure
• Stovepiped information systems are redundant
  and cannot interoperate, and data is repetitive
  and inconsistent
• Proprietary interfaces ? standard
• Less vertical integration
• Diversification

36
Hypothetical Case Study IM

• What are the components? Their functions?
• What could/should be standardized?
• What would be in a reference implementation?
• Who are the stakeholders and what are their
  likely strategies?

37
Summary

• Understand standards definition and adoption
  processes
• Analyze stakeholder interests and strategies