How Standards Happen*

*and why sometimes they don’tAddison PhillipsInternationalization Architect

Yahoo! Inc.

About Me…

Internationalization Architect, Yahoo!

Standards Busybody Unicadet (formerly) W3C I18N WG, I18N WSTF,

I18N Core WG Editor, BCP 47 (LTRU, aka RFC 3066bis)

How I got involved in standards

(a cautionary tale)

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

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.

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.

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 you’re the gorilla.)

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

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

De jure standards

Definitely: Documented. Normative. “Official” (imprimatur) Consensual.

Sometimes: Non-proprietary Open

Success criteria

To succeed, standards need four different kinds of commitment

Commitment to the Problem

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

Commitment to the Solution

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

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 what’s going on) Working Groups (table to sit at)

Chairs Editors Procedures

Oversight Publication rules “Standards Track” AppealsPolitic

s, Secret H

andshakes, Jargon, R

ituals, Mumbo-Jumbo

Commitment to Implementation

Not just theory! Implementation Interoperability Validation Experience Best Practices

“Interpret the standard”

Core concerns vs. nifty ideas

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

Putting it together

Problem: agree not to disagree Solution: pool resources, seek

consensus Implementation: interoperate Support: embrace, promote

Standards are a consensual activity

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.

Alchemy of the Standards Process

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

At last…

… the example, complete with squeals

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

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

Rough time line, 3066bis

2002 W3C I18N Roundtable Suzanne Toppings’ Multilingual article Tex’s 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” document2004 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 commissioned2005 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?

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

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 #)

Inte

rnet-D

rafts a

ny

time

Modesty Panel

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.

CONTENT WARNING

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

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 anyone’s particular business Tools make for the wrong audience (translators)

Lack of vision, not technology: Repositories and document workflow systems UI standardization Writing standards

When Standards Fail

CORBA: Both users love it. W3C CharMod: Nine years in

gestation and still not done… can’t get anyone to implement Form C in an XML processor.

Other globalization standards: Insert your favorite here!

Discussion