Making Standards - A Cautionary Tale
This page contains notes for a presentation about developing technical standards for the Internet and World Wide Web. It is based on my own personal experiences of a failed attempt to develop a new all-encompassing standard for reliable messaging. I argue that there are areas of work being undertaken in RTS, specifically related to web portal technology, that are potentially prey to the same mistakes that characterized my earlier work in Internet standards.
Contents:
1. Presentation
The presentation is here: attachment:20060426-MakingStandards.zip.
The slides consist of an HTML file containing the main content, plus a number of css and js files that are the "slidy" presentation system (e.g. see http://www.w3.org/Talks/Tools/Slidy/ for both demo and explanation).
I've slightly modified the css from the W3C copy (removed their logo!), and set things up so the slides refer to the templates via relative path "../slidy/...". Thus the directory layout in the attached ZIP file. Thus you should be able to unzip into an empty directory, and open the HTML file in your browser. Similarly if you want make them available for direct HTTP viewing.
2. Original outline notes
- The 5GM story (true!)
- The vision (the cabbages are back in town)
- Next-generation fax - reliable messaging
- Internet and PSTN transports
- Confirmed delivery
- Content negotiation
- Timely delivery
- Legal admissibility
- Computer processable and final-form documents
- e.g. Wordprocessor and PDF
- The all-encompassing design
- A combined system design for all of the above
- Consulting with Dave Crocker
- The goals were valid
- The means were not
- Using Internet mail standards: MIME, security, SMTP, etc.
- But did not respect the Internet mail architecture
- Deployment was all-or-nothing
- Interworking with deployed email was an afterthought
- Even the name was arrogant (5GM = 5th Generation Messaging)
- The vision (the cabbages are back in town)
- Standards
- The nice thing about standards is that there are so many to choose from!
- Need to choose carefully and wisely
- Ticking the check-boxes isn't enough
- It's not how many (or few) standards you use that counts, but how many others use the same ones
- Standards work best when they address small, focused, widely experienced needs
- It has been said of broad standards that they "Fill a much-needed gap"
- Decompose user requirements into smaller functional requirements
- Look for existing standards to deal with the functional requirements
- Look to use standards that are widely used across several application domains
- Applications can be constructed as a weaving of existing standards with new designs introduced only for functional requirements not already covered.
Applications may be monolithic, standards should not be
- Don't Repeat Yourself (DRY) applies in spades to standards
- Standards work best when they address small, focused, widely experienced needs
- The nice thing about standards is that there are so many to choose from!
- G5 Messaging: Picking apart the pieces
- Reliable delivery
is not the real requirement
- deliver, or tell me if you cannot
- Confirmed delivery
- requires a closed-loop communication
- guaranteed end-to-end confirmation is dififcult in email architecture
- MTA confirmation is achievable, sort-of
- end-to-end confirmation falls foul of privacy concerns
- people and automated end-points
- Content negotiation
- requires capability description
- requires a closed-loop communication
- Timely delivery
- requires time limit for round trip message exchanges
- requires a closed-loop communication
- what happens if messages are lost?
- cf. TCP
- Reliable delivery
- Internet Fax
- Bellheads and Netheads - when social worlds collide
2 years to agree an image format
- Difficult problems deferred
- The real gain: learning to communicate
- Two more rounds
- Capability announcement
- Cross-ferlilization with Web-based standards work
- ...
- Timely delivery
- Difficult in email
- It's not the speed, but determinacy
- almost solved, but couldn't quite resolve all problems
- Flirtation with instant messaging
- Difficult in email
- Content negotiation
- Capability announcement
- Observations from Internet Fax work
- Deployability: build on what already exists in the field
- Designing extensions to widely-deployed infrastructure
- Working with existing deployed is standards hard
- With care results can be achieved
- Some functional compromises may be inevitable
- We actually achieved standards-track status for designs covering about 80-90% of the technical requirements of 5GM
- Successful standards != successful deployment
- What does this have to do with us?
- Federated authentication
- Portals
- Federated authentication
- SAML 1.0, 1.1
- Liberty alliance 1.1, 1.2
- Shibboleth 1
- 5 incompatible standards addressing different requirements
- But the community appear to be doing the right thing
- SAML 2.0 provides common framework with pieces to address all requirements
- Two constrained delegation profiles
- Shibboleth 2 to use profile of a common framework agreed betweeen education and Liberty alliance groups
- SAML 2.0 provides common framework with pieces to address all requirements
- Experienced Internet/Web standards-makers
- Using and converging existing standards where possible
- Portals
- Goals
- Aggregation of presentation
- Persistent personalization
- Single sign-on
- Multi-view synchonization
- Portals embody the "all encompassing design"
- Protocol standards derived from Java API - the tail wagging the dog?
- WSRP standard development appears to be moribund - proprietary systems abound
- WSRP substantially duplicates other developments
- Creating a (sub-functional) web within the Web
- "With enough thrust ... even a cow can achieve orbit"
- Separation of concerns
- Aggregation of presentation
- Currently performed in a "server"
- This might be performed in future browsers
- Not really a server function, but a user-agent function
- Distributed UA architectures are not new; cf. email
- Persistent personalization
- Personalization description required
- Use existing protocols for persistence
- Standard HTTP would do!
- Single sign-on
- Why special for portals
- Also needed for Grid applications
- SAML and Shibboleth are not portal specific
- Avoid portal-specific solutions
- Aggregation of presentation
- Are portals a dead-end?
- If pursuing the current directions, then I predict they will become severely marginalized if not irrelevant.
- Can this be avoided?
- I think there is still hope
- Start with inter-portlet communication [1]:
- Replace (yet another) private message passing protocol with a generic event propagation mechanism based on existing protocols (e.g. presence protocols)
- Avoid portal-specific solutions: develop mechanisms for browsers to recive event notifications
- Demonstrate that new problems can be solved in other ways than adding further state management and complexity to existing portal software and standards - this may in turn lead to a migration of other functionality away from complex and fragile portal software
Try to replace portal-specific solutions with solutions that are also available to an ordinary browser
- Goals
3. References
http://wiki.oss-watch.ac.uk/InterPortletCommunicationConsideredHarmful - alternative proposal for dealing with requirements giving rise to inter-portlet communication specifications.
-- GrahamKlyne 2006-03-07 13:07:04
