The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Last modified: September 28, 2010
XML Daily Newslink. Tuesday, 28 September 2010

A Cover Pages Publication
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Microsoft Corporation Developers Create The Document Foundation and LibreOffice
Staff, The Document Foundation Announcement

Formation of "The Document Foundation" has been announced by a "community of volunteers" who have supported development of the software. According to the organization's web site, The Document Foundation is "an independent self-governing meritocratic Foundation, created by leading members of the Community. It continues to build on the foundation of ten years' dedicated work by the Community. It was created in the belief that the culture born of an independent Foundation brings out the best in contributors and will deliver the best software for users. It is open to any individual who agrees with our core values and contributes to the community activities. The Document Foundation welcomes corporate participation, e.g. by sponsoring individuals to work as equals alongside other contributors in the community."

Statements of support for The Document Foundation and LibreOffice have been published from: Google, Novell, Red Hat, Canonical, the Open Source Initiative, Sophie Gautier (for the French community),, the Norwegian Foundation, Deutschland e.V., the GNOME Foundation, NeoOffice, credativ, Collabora, Liberix, OOoES, the OpenDocument Fellowship, Free Software Foundation (FSF) President Richard Stallman, the Native Language Confederation, IST planbar GmbH, the UK Open Source Consortium, BSRSoft LTDA, and others.

From the announcement: "After ten years' successful growth with Sun Microsystems as founding and principal sponsor, the project launches an independent foundation called "The Document Foundation", to fulfil the promise of independence written in the original charter. The Foundation will be the cornerstone of a new ecosystem where individuals and organisations can contribute to and benefit from the availability of a truly free office suite. It will generate increased competition and choice for the benefit of customers and drive innovation in the office suite market. From now on, the community will be known as 'The Document Foundation'.

Oracle, who acquired assets as a result of its acquisition of Sun Microsystems, has been invited to become a member of the new Foundation, and donate the brand the community has grown during the past ten years. Pending this decision, the brand 'LibreOffice' has been chosen for the software going forward. The Document Foundation is the result of a collective effort by leading independent members of the former community, including several project leads and key members of the Community Council. It will be led initially by a Steering Committee of developers and national language projects managers. The Foundation aims to lower the barrier of adoption for both users and developers, to make LibreOffice the most accessible office suite ever. The Foundation will coordinate and oversee the development of LibreOffice, which is available in beta version [...], developers are invited to join the project and contribute to the code in the new friendly and open environment, to shape the future of office productivity suites alongside contributors who translate, test, document, support, and promote the software..."

See also: The Document Foundation web site

OASIS Announces Public Review for WS-Calendar Specification
Toby Considine and Mike Douglass (eds), OASIS Committee Drafts

On September 24, 2010, OASIS announced a 60-day public review for the Committee Draft 01 version of WS-Calendar, including the core WS-Calendar Version 1.0 specification (with XML schema files, RDDL, EAP) and the companion White Paper Conceptual Overview of WS-Calendar: Understanding Inheritance Using the Semantic Elements of Web Services.

WS-Calendar "describes a limited set of message components and interactions providing a common basis for specifying schedules and intervals to coordinate activities between services. The specification includes service definitions consistent with the OASIS SOA Reference Model and XML vocabularies for the interoperable and standard exchange of: (1) Schedules, including sequences of schedules; (2) Intervals, including sequences of intervals. These message components describe schedules and intervals future, present, or past (historical). The definition of the services performed to meet a schedule or interval depends on the market context in which that service exists. It is not in scope for this TC to define those markets or services...

The WS-Calendar specification adapts the existing specifications for calendaring and apply them to a new specification for how schedule and event information is passed between and within services. The standard adopts the semantics and vocabulary of iCalendar for application to the completion of web service contracts. WS Calendar builds on work done and ongoing in The Calendaring and Scheduling Consortium (CalConnect), which works to increase interoperation between calendaring systems, and the Internet Engineering Task Force (IETF).

The specification describes how to specify a sequence of services, how to schedule them, and how to invoke them. The specification was developed to support use cases in smart grids and smart energy, but it supports any sort of coordinated activities between domains. The committee explicitly considered coordination between energy coordination, enterprise systems, building systems, and financial markets. The specification also defines an inheritance approach wherein information common to many time intervals is specified for an entire sequence, while supporting over-rides within any time interval..."

See also: the CalConnect XML Technical Committee

W3C First Public Working Draft: The Media Capture API
Dzung D. Tran, Ilkka Oksanen, Ingmar Kliche (eds), W3C Technical Report

Members of the W3C Device APIs and Policy Working Group have released a First Public Working Draft for the specification The Media Capture API. This specification defines an Application Programming Interface (API) that provides access to the audio, image and video capture capabilities of the device.

Details: "The Capture API defines a high-level interface for accessing the microphone and camera of a hosting device. It completes the HTML Form Based Media Capturing specification with a programmatic access to start a parametrized capture process. The terms 'camera application,' 'camcorder application', and 'audio capture application' are used to refer piece of an(y) interactive software implemented either by the user agent or the underlying operating environment that carry out the actual capture operation...

The API defined in this specification launches the capture application which allows the user to take pictures, record voice or record video and provides a handle to the content. This information can potentially compromise user privacy and a conforming implementation of this specification must provide a mechanism that protects the user's privacy and this mechanism should ensure that such operations must not happen without user consent. [So] a conforming implementation of this specification must provide a mechanism that protects the user's privacy and this mechanism should ensure that privacy information is not revealed without user's informed consent..."

The W3C Device APIs and Policy Working Group members have also published an updated version of the HTML Media Capture specification. The HTML Form Based Media Capturing specification "defines a new interface for media files, a new parameter for the accept attribute of the HTML input element in file upload state, and recommendations for providing optimized access to the microphone and camera of a hosting device."

See also: the HTML Media Capture WD

IETF WG Proposal: Application Bridging for Federated Access Beyond Web
Staff, IESG Secretary Announcement

From the Internet Engineering Steering Group (IESG) Secretary: "A new IETF Working Group has been proposed in the Security Area. The IESG has not made any determination as yet, [but a] draft charter was submitted, and is provided for informational purposes; please send your comments to the IESG by Tuesday, October 5, 2010.

The IETF Proposed Working Group is "Application Bridging for Federated Access Beyond web (ABFAB)." Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML).

Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML and SAML message formats are used to carry subject information that can be used for authorization and personalization by a relying party. Any change in the choices for these three technical roles is out of scope for this charter... Initially the working group will focus on using GSS-API (RFC 2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process.

The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC) and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding..."

See also: the IETF Internet Draft for 'A RADIUS Attribute for SAML Constructs'

Five Problems with SaaS Security
Jon Brodkin, ComputerWorld

"Total cost of ownership used to be the most frequently cited roadblock among potential SaaS customers. But now, as cloud networks become more frequently used for strategic and mission-critical business applications, security tops the list.

First, Identity management in the cloud is immature. Cloud providers themselves aren't always sophisticated about integrating their platforms with identity services that exist behind the enterprise firewall, says Forrester analyst Chenxi Wang. There are some third-party technologies that let IT extend role-based access controls into the cloud with single sign-on, from Ping Identity and Symplified, Wang says...

Unfortunately, the evolution of SaaS has outpaced efforts to build comprehensive industry standards, the Cloud Security Alliance says. Specifically, the group says there is 'limited proprietary support for user profiles,' and industry standards including Service Provisioning Markup Language (SPML) have not been significantly updated in several years.

Second, Cloud standards are weak. 'We've completed a SAS 70 audit' is one of the first things you'll hear from any cloud vendor touting its security credentials. SAS 70 is an auditing standard designed to show that service providers have sufficient control over data. The standard wasn't crafted with cloud computing in mind, but it's become stand-in benchmark in the absence of cloud-specific standards. Better than SAS 70 is ISO 27001, an information security specification published by ISO [but] there's no guarantee that your data will be safe with an ISO 27001-compliant vendor, however. One survey of IT managers commissioned by CA found numerous companies that claim to be compliant with ISO 27001 yet 'admit to bad practices with regard to privileged user management'..."

See also: the Service Provisioning Markup Language (SPML)

Open Grid Forum Releases WS-Iterator 1.0 Specification for Review
Mark Morgan (ed), OGF Review Specification

Members of the Open Grid Services Architecture (OGSA) Naming Working Group have published a draft version of WS-Iterator 1.0 for public review through November 22, 2010. This OGF working group was chartered "to work on two specifications (RNS and WSNR) to realize a three level name space for OGSA and to produce WS-Naming naming specification based on WS-Addressing. Thus, both RNS and WS-Naming must be combinable with OGSA Basic Profile."

From the document Abstract: "A number of grid services aggregate data together in lists or maps as part of their inherent function. Consider RNS (the Resource Namespace Specification) which provides the means of mapping human readable names to resource endpoints. Also consider a grid queue or cluster management system that might both group together target or backend BESs (Basic Execution Services) as well as provide mechanisms for querying or manipulating lists of queued jobs. Numerous other examples exist.

In both of these cases, it is unreasonable and inefficient to expect communication where the entire content of such a group is transferred in a single SOAP document. At the same time, given the potentially large and diverse spectrum of likely uses for which iteration might be ideal, a generic form of iteration is desirable—one for which iterable content is extensible. A number of iteration service specifications exist already; in particular WS-Enumeration provides similar functionality.

Unfortunately, WS-Enumeration is based off of an entirely different model of web service endpoint interaction then that of WSRF. While WSRF has adopted a notion of the 'implied' target resource as identified by WS-Addressing information included in the request message's SOAP headers, WS-Enumeration uses a more service oriented, 'token-in-the-soap-body' protocol. As such, in cases where grid service design is heavily influenced by and modeled after a WSRF pattern, WS-Enumeration is confusing and ungainly. In those cases, WS-Iterator provides the same functionality in a way that is more consistent with intended WSRF practices. A more detailed description of why the existing WS-Enumeration specification is not suited to this task of WSRF-based iteration [is available online]..."

See also: OGF documents open for public comment

Cloud Vendors Seek Better Legal Protections for Online Data
Patrick Thibodeau, ComputerWorld

"Executives from top cloud vendors Microsoft, Google,, and Rackspace have urged a congressional committee to support their goal of giving data stored in cloud computing systems the same legal protections as information stored on one's personal computer. The lack of such protections today is a particularly important issue for enterprise customers, and is deterring some from using cloud services...

To give lawmakers a sense of the scale of cloud-based system use, Google senior counsel Richard Salgado told the committee that there are 3 million business users of the company's cloud services today, and about 3,000 more sign up for them each day.

Michael Hintze, associate general counsel at Microsoft, said that users of its Business Productivity Online Suite, which includes a document storage product, include companies that must protect highly confidential information, including trade secrets, business plans and customer lists: 'Enterprise users tell us that they are very concerned about the privacy implications for moving such sensitive data from local storage to remote storage; a significant part of that concern relates to the circumstances under which the government can compel disclosure of data from third party providers'...

Similarly, David Schellhase, executive vice president and general counsel of, said that its customers, especially those based outside the country, want assurances that the U.S. government will not access their data without deliberate due process. Opposition to changes in the law may come from law enforcement agencies..."

See also: the OASIS Identity in the Cloud Technical Committee

Requirements, Terminology and Framework for Exigent Communications
Henning Schulzrinne, Steve Norreys (et al, eds), IETF Internet Draft

Members of the IETF Authority-to-Citizen Alert (ATOCA) Working Group have released an initial level -00 WG Draft Requirements, Terminology and Framework for Exigent Communications. This IETF Working Group was chrtered to specify "how an Authority-to-Citizen Alert (ATOCA) system can verify authorization and deliver messages to the intended recipients. A critical element of the work are the mechanisms that assure that only those pre-authorized agents can send alerts via ATOCA, through an interface to authorized alert distribution networks (e.g., iPAWS/DM-Open in the U.S.)...

There are a variety of mechanisms that authorities have available to notify citizens and visitors during emergency events. Traditionally, they have done so with broadcast networks (radio and television). For commercial mobile devices, broadcasting services such as the Public Warning System (PWS), the Earthquake and Tsunami Warning System (ETWS), and the Commercial Mobile Alert System (CMAS) are standardized and are in various stages of deployment. The general message pattern that this group is intended to address is the sending of alerts from a set of pre-authorized agents (e.g., governmental agencies) to a large population without undue impacts on the networks serving that population. In particular, the message pattern specified should avoid congestion and other denials of service.

From the Working Draft Abstract: "Before, during and after emergency situations various agencies need to provide information to a group of persons or to the public within a geographical area. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document provides terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points.

The term 'Exigent Communications' in this I-D aims to generalize the concept of conveying alerts to IP-based systems and at the same time to re-define the actors that participate in the messaging communication... Traditionally, emergency alerting has used church bells, sirens, loudspeakers, radio and television to warn citizens and to provide information. However, techniques, such as sirens and bells, provide limited information content; loud speakers cover only very small areas and are often hard to understand, even for those not hearing impaired or fluent in the local language. Radio and television offer larger information volume, but are hard to target geographically and do not work well to address the 'walking wounded' or other pedestrians. Both are not suitable for warnings, as many of those needing the information will not be listening or watching at any given time, particularly during work/school and sleep hours...."

See also: the IETF Authority-to-Citizen Alert (ATOCA) Working Group

How to Move Your Messaging Infrastructure to the Cloud
Gregory Shapiro, eWEEK

"When it comes to moving a messaging infrastructure to the cloud, the potential benefits of lowered costs, increased storage and flexibility hold promise. The strategy for any enterprise planning to move its messaging infrastructure to the cloud, however, should include awareness of possible pitfalls, compromises and unexpected losses of functionality and security. In this article, Gregory Shapiro [SendMail] explains five things to consider before moving your messaging infrastructure to the cloud...

At first, it may seem as if moving your e-mail infrastructure to the cloud is a no-brainer, as the upkeep, capacity planning and troubleshooting becomes someone else's problem. However, the benefits outsourcing to the cloud offers brings risks that need to be carefully weighed for each portion of the e-mail infrastructure—before making a decision to keep it in-house or put it in the cloud. In the end, the most likely outcome is a hybrid infrastructure that makes use of both cloud services and in-house infrastructure.

Five benefits and associated risks of moving relevant pieces of infrastructure to the cloud are considered here. These items involve costs, responsibility, trust, control, functionality and security. When it comes to control, there isn't much to offer in terms of benefits.: (1) Lack of control over data retention policy for backups, storage, logs, etc. (2) Providers may be subpoenaed and required to turn over your data without notification due to gag orders—for example, National Security Letters. (3) Little to no control over the provider's maintenance cycles or downtime. (4) Providers or their partners may be acquired by organizations that may have different privacy policies, partners, terms of service, etc. They may also go out of business. The importance each of these depends on the corporate culture and the portions of the infrastructure being considered.

When considering moving the Backbone or Groupware Layers to the cloud, security presents the biggest and most important risk. Doing so exposes all of the data at rest necessary to implement enterprise policy and deep content inspection, including enterprise directory data, sensitive documents to be fingerprinted, and archived and quarantined data, to name a few... In the end, who is responsible for your e-mail? Think about your own messaging infrastructure. If you use cloud services or are considering a move to the cloud, it's important to understand that. While the promises of cloud computing can be potentially realized by migrating different layers of the messaging infrastructure to the cloud, it's also critical to address the risks involved..."


XML Daily Newslink and Cover Pages sponsored by:

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

XML Daily Newslink:
Newsletter Archive:
Newsletter subscribe:
Newsletter unsubscribe:
Newsletter help:
Cover Pages:

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: