How Standards Happen*
*and why sometimes they don’t
Addison Phillips
Internationalization 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



Requirements for de jure
standards
Life of a standard


The “marketplace” of standards
RFC 3066bis
Some soul-searching and
discussion
Why Standards are Good Things

Promote access.



Promote interoperability


Unicode gives every language access to
modern technology.
HTML gives everyone the ability to publish
(and read) content.
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:




Initially: Maximizes innovation


Use differentiation to win market share
Become the “winner”
Closing off future choice
“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”
Appeals
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



Improvements:



Accommodation
Proprietary disadvantage
Version 2.0 improves on version 1.0
Documentation, promotion, demystification
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

2003
Maybe a problem with locales?
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?


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 InternetDrafts
RFC 3978 standards surrender IPR

Informational, experimental: can be
proprietary
IETF Standard Process

Charter WG (IESG)
Internet-Drafts any time






Create drafts
WG Last Call
Chair requests publication as an RFC
IETF Last Call
IESG Approval





AD, Chairs, Editors
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 #)
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