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.competitionnatural monopolydot-comstart-ups high technology

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 LTRU WG commissioned 2005 draft-registry-00 (March) draft-14 of draft-registry W3C: xml:lang in document schemas FAQ IETF last call succeeds (November) Registry in operation (December) 2006 Multilingual articles W3C I18N FAQ draft-13 of draft-matching, BCP 47 status? 2007 update to include ISO 639-3?

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 #) Internet-Drafts any time

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