How Standards Happen*

1
How Standards Happen

• and why sometimes they dont
• Addison Phillips
• Internationalization Architect
• Yahoo! Inc.

2
About Me

• Internationalization Architect, Yahoo!
• Standards Busybody
• Unicadet
• (formerly) W3C I18N WG, I18N WSTF, I18N Core WG
• Editor, BCP 47 (LTRU, aka RFC 3066bis)

3
How I got involved in standards

• (a cautionary tale)

4
Agenda, or everything but the squeal

• De facto vs. de jure
• The marketplace of standards
• Requirements for de jure standards
• Life of a standard
• RFC 3066bis
• Some soul-searching and discussion

5
Why Standards are Good Things

• Promote access.
• Unicode gives every language access to modern
  technology.
• HTML gives everyone the ability to publish (and
  read) content.
• Promote interoperability
• Universal access produces the Network Effect.
• Promotes innovation
• The larger the community, the larger the
  potential return for innovation.

6
De facto standards winner takes all

• Wikipedia definition
• In business, a Winner Takes All market is a
  competition for a natural monopoly. In the
  dot-com economy the impetus for many start-ups to
  quickly increase in size stemmed from the
  perception that high technology markets are
  natural monopolies, so that only one firm can
  survive and reap monopoly rents.

7
Winner takes all (2)

• One big gorilla, a few secondary players,
  everyone else is an ant or cannon fodder.
• Examples
• OS (Microsoft, Apple, Linux,)
• Databases (Oracle, IBM, Microsoft,)
• (This is good, if youre the gorilla.)

8
The de facto standard

• Why
• Use differentiation to win market share
• Become the winner
• Closing off future choice
• Initially Maximizes innovation
• market of ideas
• Later Stifles innovation
• Lock-in, network effect, reliance

9
Are de facto standards Bad?

• No... they are often the basis for de jure
  standards.
• Locales (circa 1990)
• japanese, french, german, C
• ENU, FRA, JPN
• ja_JP.PCK
• AMERICAN_AMERICA.WE8ISO8859P1
• RFC 1766 (1995)
• ja-JP, de, de-CH

10
De jure standards

• Definitely
• Documented.
• Normative.
• Official (imprimatur)
• Consensual.
• Sometimes
• Non-proprietary
• Open

11
Success criteria

• To succeed, standards need four different kinds
  of commitment

12
Commitment to the Problem

• Communities must recognize a problem and must
  recognize the need for a standard as the solution.

13
Commitment to the Solution

• The community must seek to incorporate divergent
  viewpoints and seek consensus.

14
Commitment to the Solution

• Binding rules! Level playing field!
• which need to be created and maintained.
• The community must identify contributors and
  commit resources to the problem
• Organizations (rules of order)
• Communications (find out whats going on)
• Working Groups (table to sit at)
• Chairs
• Editors
• Procedures
• Oversight
• Publication rules
• Standards Track
• Appeals

Politics, Secret Handshakes, Jargon, Rituals,
Mumbo-Jumbo
15
Commitment to Implementation

• Not just theory!
• Implementation
• Interoperability
• Validation
• Experience
• Best Practices
• Interpret the standard
• Core concerns vs. nifty ideas

16
Commitment to Support

• Successful implementation ? pressure to adopt
  standard
• Accommodation
• Proprietary disadvantage
• Improvements
• Version 2.0 improves on version 1.0
• Documentation, promotion, de-mystification
• Continued interest and promotion leads to
  continued adoption

17
Putting it together

• Problem agree not to disagree
• Solution pool resources, seek consensus
• Implementation interoperate
• Support embrace, promote
• Standards are a consensual activity

18
Dirty Secrets

• Standards are made by people
• Standards take time
• Require consensus not just of the standards
  participants, but in general
• Require focus participation needs to be timely.
• Part of your day job participation needs to be
  relevant.

19
Alchemy of the Standards Process

• What goes in is not what comes out!
• Camel horse designed by committee
• Hybrid vigor

20
At last

• the example, complete with squeals

21
IETF

• Internet Engineering Task Force
• Rough Consensus and Running Code
• Who IETF R Us
• Tracks STD, BCP, Experimental
• How Internet-drafts, RFCs
• By Working Groups or individuals

22
BCP 47

• Language tags
• De facto practice (POSIX?)
• RFC 1766 (March 1995)
• RFC 3066 (January 2001)
• RFC 3066bis (November 2005)
• Plus draft-ietf-ltru-matching
• And also draft-ietf-ltru-initial-06
• LTRU WG

23
Rough time line, 3066bis

• 2002
• W3C I18N Roundtable
• Suzanne Toppings Multilingual article
• Texs locales list
• Maybe a problem with locales?
• 2003
• IUC 22 presentation, panel
• ULocale paper
• Web services locales paper
• IUC 23 presentation, entente cordial
• (individual submissions, discussion on
  ietf-languages list begins)
• draft-00 of draft-langtags (10 in total)
• reasons document
• 2004
• W3C WSUS, WSReq (July)
• W3C WS-CC Position Paper (September)
• D.Ewell, A.Phillips langtag interop
• Langtag tests
• draft-10 fails IETF last call

24
De jure rules of the road

• RFC 2026 (STD 9) governs process
• Things done in public, on mailing lists, or at
  meetings
• RFC 2223bis governs Internet-Drafts
• RFC 3978 standards surrender IPR
• Informational, experimental can be proprietary

25
IETF Standard Process

• Charter WG (IESG)
• AD, Chairs, Editors
• Create drafts
• WG Last Call
• Chair requests publication as an RFC
• IETF Last Call
• IESG Approval
• Can appeal to IAB
• RFC (eventually) published as Proposed Standard
• At least two interoperable implementations
• IESG approves publication as Draft Standard
• IESG approves publication as Standard (STD )

26
Modesty Panel
27
De facto rules of the road

• You SHOULD have a crank.
• You MUST use tools and procedures.
• You MUST develop an understanding of IETF ABNF
  and become conversant with relevant RFCs.
• You MUST have a hum.
• You MUST navigate IETF politics.
• You SHOULD NOT submit individual submissions.

28
CONTENT WARNING

• The following slide contains scenes of unprovoked
  generalization and provocative statements that
  may be offensive or naïve. Viewer discretion is
  advised.

29
Language Standards a rocky history

• Lack of unity
• LSPs, tool vendors seek lock-in
• Efficiency disincentive (paid per word, not paid
  for engineering)
• Easier to make vendors work than fix processes
• Non-ownership of the real problem (content)
• Immaturity of GILT vs. core business
• Not core to anyones particular business
• Tools make for the wrong audience (translators)
• Lack of vision, not technology
• Repositories and document workflow systems
• UI standardization
• Writing standards

30
When Standards Fail

• CORBA Both users love it.
• W3C CharMod Nine years in gestation and still
  not done cant get anyone to implement Form C in
  an XML processor.
• Other globalization standards
• Insert your favorite here!

31
Discussion