Cover Pages: XML Daily Newslink: Tuesday, 28 July 2009

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Oracle Corporation http://www.oracle.com

Headlines

User Agent Accessibility Guidelines (UAAG) 2.0: Updated Working Draft
Transport of Real-time Inter-network Defense (RID) Messages
OASIS Energy Market Information Exchange Technical Committee Charter
Apache Tuscany SCA Java Version 2.0-M3
Dynamic Symmetric Key Provisioning Protocol (DSKPP)
OASIS Call for Review: Common Alerting Protocol 1.2 IPAWS Profile
Easy Syndication: Creating an Atom feed in PHP
Reveling in Constraints
The First Few Milliseconds of an HTTPS Connection

User Agent Accessibility Guidelines (UAAG) 2.0: Updated Working Draft
J. Allan, K. Ford, J. Richards, J. Spellman (eds), W3C Technical Report

Members of the W3C User Agent Accessibility Guidelines Working Group have published a revised version of the "User Agent Accessibility Guidelines (UAAG) 2.0" specification. There is a diff-marked version showing revisions since 11-March-2009, and an additional diff-marked version showing changes in response to public comments.

This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities. User agents include browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable. In addition to helping developers of browsers and media players, this document will also benefit developers of assistive technologies because it explains what types of information and control an assistive technology may expect from a conforming user agent. Technologies not addressed directly by this document (e.g., technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities..."

UAAG is part of a series of accessibility guidelines/standards developed by WAI, including Web Content Accessibility Guidelines (WCAG) and Authoring Tool Accessibility Guidelines (ATAG). UAAG 2.0 is currently informative only. After the UAAG Working Group is rechartered to produce W3C Recommendations under the W3C Patent Policy, the group expects to advance UAAG 2.0 through the Recommendation track.

Transport of Real-time Inter-network Defense (RID) Messages
Kathleen M. Moriarty and Brian H. Trammell, IETF Internet Draft

IETF has released an initial version -00 Internet Draft for the specification Transport of Real-time Inter-network Defense (RID) Messages, published earlier under the title IODEF/RID over SOAP, through the IETF Extended Incident Handling Working Group.

From the document 'Introduction': The Incident Object Description Exchange Format (IODEF) as published in RFC 5070 describes an XML document format for the purpose of exchanging data between Computer Security Incident Response Teams (CSIRTs) or those responsible for security incident handling for network providers (NPs). The defined document format provides an easy way for CSIRTs to exchange data in a way which can be easily parsed.

IODEF defines a message format, not a transport protocol, as the sharing of messages is assumed to be out of scope in order to allow CSIRTs to exchange and store messages in a way most suited to their established incident handling processes. However, extensions such as Real-time Inter-network Defense (RID) (IETF I-D "Real-time Inter-network Defense" do require a specification of a transport protocol to ensure interoperability among members in a RID consortium.

This document specifies the transport of RID messages within HTTP Request and Response messages transported over TLS, per RFC 5246. Note that any IODEF message may also be transported using this mechanism, by sending it as a RID Report message. For transmission of RID Messages over HTTP/TLS, each RID server is both an HTTP/ TLS server and an HTTP/TLS Client. When a RID message must be sent, the sending RID system connects to the receiving RID system and sends the message, optionally receiving a message in reply. All RID systems must be prepared to accept HTTP/TLS connections from any RID peer with which it communicates, in order to support callback for delayed replies... HTTP/TLS is not ideally suited for RID transport, as the former is a client-server protocol and the latter a message-exchange protocol; however, the ease of implementation of RID systems over HTTP/TLS outweighs these concerns. Consistent with BCP 56, RID systems will listen for TCP connections on [a port to be defined]...

OASIS Energy Market Information Exchange Technical Committee Charter
William Cox, OASIS 'smartgrid-interest' List Announcement

OASIS members supporting a new "Energy Market Information Technical Committee" announced the finalization of a draft charter, requesting input from parties interested in being identified as supporting this new work.

"The proposed EMIX work addresses portions of the price cross cutting issue and priority action plan in the NIST Smart Grid program, though the genesis predates that work... This TC is intended to address the prices, market characteristics, and other information for energy trading, buying, and selling. I was inspired to start working on this from discussions in and around the NIST Building-to-Grid and Industry-to-Grid Domain Expert Working Groups, and continued interest from first round reviewers and from people attending GridEcon 2009 in Chicago... From my perspective as an enterprise software architect, this fits into a simple three layer stack with interoperation protocols (how to communicate) as the fundamental layer. I put the OASIS Energy Interoperation TC/OpenADR work here with parts of the message payload in the next layer...

The middle layer is what is communicated—for markets, things like price, quantity, units, time (of use), and characteristics of the energy sold—from source (e.g. gas-fired plants, coal, solar, coal plant with scrubbers, wind) to derived information (e.g. carbon data), and also trading information (is this a bid, a price quote, an accepted transaction?). The goal is to create an XML vocabulary that can be used in a broad range of market exchanges with minimal differences (and where there are differences, arranged in a simple way) for the various consumers of the information. The third layer is the marke t design and definition..."

See also: the OASIS announcement

Apache Tuscany SCA Java Version 2.0-M3
Ant Elder, Apache Software Announcement

Members of the Apache Tuscany team have announced the third milestone release of the Tuscany SCA 2.0 project. Apache Tuscany provides a runtime environment based on the Service Component Architecture (SCA) which are a set of specifications aimed at simplifying SOA application development. The first SCA specifications where published by the Open SOA Collaboration group (www.osoa.org) and are implemented in the Tuscany 1.x runtime, the specification are now being standardized at OASIS as part of the Open Composite Services Architecture (Open CSA) and these are the basis of this new Tuscany 2.x runtime.

The main features of this third milestone release are new support for the BPEL and Spring specifications, support for ZIP format contributions, and a new easy to install SCA runtime for Apache Tomcat. The RELEASE_NOTES and CHANGES file present more details about the M3 release.

"Apache Tuscany offers solution developers several advantages: (1) A model for creating composite applications by defining the services in the fabric and their relationships with one another, where services can be implemented in any technology. (2) Enables service developers to create reusable services that only contain business logic; protocols are pushed out of business logic and are handled through pluggable bindings, lowering the development cost. (3) Applications can easily adapt to infrastructure changes without recoding since protocols are handled via pluggable bindings and quality of services (transaction, security) are handled declaratively. (4) Existing applications can work with new SCA compositions; this allows for incremental growth towards a more flexible architecture, outsourcing or providing services to others..."

See also: the Apache Tuscany web site

Dynamic Symmetric Key Provisioning Protocol (DSKPP)
Andrea Doherty, Mingliang Pei, Salah Machani, Magnus Nystrom; IETF Internet Draft

Members of the IETF KEYPROV Working Group have published an updated level -08 version of the "Dynamic Symmetric Key Provisioning Protocol (DSKPP)" specification. This technical work builds on information contained in "Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1" (IETF Informational RFC 4758), adding specific enhancements in response to implementation experience and liaison requests.

Symmetric key based cryptographic systems (e.g., those providing authentication mechanisms such as one-time passwords and challenge-response) offer performance and operational advantages over public key schemes. Such use requires a mechanism for provisioning of symmetric keys providing equivalent functionality to mechanisms such as CMP and CMMC in a Public Key Infrastructure... This document describes the Dynamic Symmetric Key Provisioning Protocol (DSKPP), a client-server protocol for provisioning symmetric keys between a cryptographic module (corresponding to DSKPP client) and a key provisioning server (corresponding to DSKPP server).

DSKPP provides an open and interoperable mechanism for initializing and configuring symmetric keys to cryptographic modules that are accessible over the Internet. The description is based on the information contained in RFC 4758, and contains specific enhancements, such as User Authentication and support for the PSKC format for transmission of keying material. DSKPP has two principal protocol variants. The four-pass protocol variant permits a symmetric key to be established that includes randomness contributed by both the client and the server. The two-pass protocol requires only one round trip instead of two and permits a server specified key to be established.

Section 8 of the I-D presents the DSKPP XML Schema. Some DSKPP elements rely on the parties being able to compare received values with stored values. Unless otherwise noted, all elements that have the XML Schema "xs:string" type, or a type derived from it, must be compared using an exact binary comparison. In particular, DSKPP implementations must not depend on case-insensitive string comparisons, normalization or trimming of white space, or conversion of locale-specific formats such as numbers. Implementations that compare values that are represented using different character encodings must use a comparison method that returns the same result as converting both values to the Unicode character encoding, Normalization Form C, and then performing an exact binary comparison.

OASIS Call for Review: Common Alerting Protocol 1.2 IPAWS Profile
Rex Brooks and Sukumar Dwarkanath (eds), OASIS Public Review Draft

Members of the OASIS Emergency Management TC have announced a 15-day public review for "Common Alerting Protocol, v. 1.2 USA Integrated Public Alert and Warning System Profile Version 1.0." From the 'Introduction': In order to meet the needs of the devices intended to receive alerts from the United States Integrated Public Alert and Warning System (IPAWS) System of Systems (SoS), this CAP v1.2 IPAWS Profile constrains the CAP v1.2 standard for receipt and translation with and among IPAWS exchange partners. The use of this Profile is not necessarily limited to the initial IPAWS Exchange Partners. It is available to all who might want to use the particular concepts defined in this specification.

The Common Alerting Protocol (CAP) provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats including the Specific Area Message Encoding (SAME) used for the United States' National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert System (EAS), while offering enhanced capabilities that include: (1) flexible geographic targeting; (2) multilingual and multi-audience messaging; (3) enhanced message update and cancellation features; (4) template support for framing complete and effective warning messages; (5) compatibility with digital encryption and signature capability; (6) facility for digital images and audio.

The Common Alerting Protocol (CAP) v1.0 and v1.1 were approved as OASIS standards before the Emergency Data Exchange Language (EDXL) project was developed. However, this Profile specification shares the goal of the EDXL project to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. Several exchange partner alerting systems of the IPAWS SoS are identified by this Profile for specific accommodation. However, the CAP v1.2-IPAWS Profile is not limited to systems. It is structured to allow inclusion of other alerting systems as deemed appropriate or necessary..."

See also: the announcement

Easy Syndication: Creating an Atom feed in PHP
Brian M. Carey, IBM developerWorks

"Atom is an XML specification that identifies information contained in a Web site. Using Atom, Web developers produce feeds that enable other Web developers (or consumers who use feed readers) to quickly locate and view information of interest on a remote site. Think of it as a Web site's index, available to anyone who wants it. Using PHP, a popular language of choice for most host providers, a Web developer can easily produce an Atom feed that can then be made available to the various feed readers and other Web developers. The ultimate result is a state-of-the-art information solution that enables the Web content to reach a much wider audience.

Atom was created in response to certain limitations in RSS. As a result, the Atom specification contains numerous advantages over RSS. Atom provides a means to define the format of the data being provided—for example, HTML, XHTML, and so on—whereas RSS does not. Atom, unlike RSS, supports internationalization with the xml:lang attribute. Atom also accepts more state-of-the-art (and standardized) date formatting, relying on Request for Comments (RFC) 3339 as opposed to RSS's RFC 822... Using PHP with MySQL, you can easily produce a Web feed that complies with the Atom standard and is always up to date because it reads directly from the database. The feed can then be read by a feed reader or embedded in other Web sites..."

See also: Atom references

Reveling in Constraints
Bruce Johnson, ACM Queue

"The Web's trajectory toward interactivity, which began with humble snippets of JavaScript used to validate HTML forms, has really started to accelerate of late. A new breed of Web applications is starting to emerge that sports increasingly interactive user interfaces based on direct manipulations of the browser DOM (document object model) via ever-increasing amounts of JavaScript. Google Wave, publicly demonstrated for the first time in May 2009 at the Google I/O Developer Conference in San Francisco, exemplifies this new style of Web application. Instead of being implemented as a sequence of individual HTML 'pages' rendered by the server, Wave might be described as a client/server application in which the client is a browser executing a JavaScript application, while the server is 'the cloud'...

We needed to supply many different implementations of UI functionality —version A for Firefox, version B for Safari, and so forth—without burdening the compiled application with the union of all the variations, thereby forcing each browser to download at least some amount of irrelevant code. Our solution is a unique mechanism we dubbed deferred binding, which arranges for the GWT compiler to produce not one output script, but an arbitrary number of them, each optimized for a particular set of circumstances... our experience in developing GWT has thoroughly convinced us that there's no need to give in to the typical constraints of Web development..."

The First Few Milliseconds of an HTTPS Connection
Jeff Moser, InfoQueue

What happens when one clicks on "Proceed to Checkout" on a website after browsing through their offerings? This is an analysis of the first milliseconds when an HTTPS connection with Amazon is established. A new page is loaded when proceeding to checkout... In the 220 milliseconds that flew by, a lot of interesting stuff happened to make Firefox change the address bar color and put a lock in the lower right corner. With the help of Wireshark, my favorite network tool, and a slightly modified debug build of Firefox, we can see exactly what's going on...

Most people associate HTTPS with SSL (Secure Sockets Layer) which was created by Netscape in the mid 90's. This is becoming less true over time. As Netscape lost market share, SSL's maintenance moved to the Internet Engineering Task Force (IETF). The first post-Netscape version was re-branded as Transport Layer Security (TLS) 1.0 which was released in January 1999. It's rare to see true "SSL" traffic given that TLS has been around for 10 years... In just 220 milliseconds, two endpoints on the Internet came together, provided enough credentials to trust each other, set up encryption algorithms, and started to send encrypted traffic. I wrote a program that walks through the handshake steps mentioned in this article..."


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors