Cover Pages: XML Daily Newslink: Thursday, 14 October 2010

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:
Microsoft Corporation http://www.microsoft.com

Headlines

Key Management Interoperability Protocol (KMIP) 1.0 an OASIS Standard
Web Accessibility Initiative (WAI): New and Improved WCAG 2.0 Techniques
NIST Releases Smart Grid Standards
W3C Invites Implementations of CSS Style Attributes Specification
Sieve Notification Using Presence Information
Survey: Cloud Benefits Not Clearly Defined
The Atom Audience Extension

Key Management Interoperability Protocol (KMIP) 1.0 an OASIS Standard
Staff, OASIS Announcement

The OASIS open standards consortium has announced the approval of the 'Key Management Interoperability Protocol (KMIP) Version 1.0' as an OASIS Standard. Developed through a collaboration of more than thirty vendors and end user organizations, KMIP enables communication between key management systems and cryptographically-enabled applications, including email, databases, and storage devices. The core KMIP document and the related KMIP Profiles, together with a Usage Guide and Use Cases document, is publicly available.

KMIP simplifies the way companies manage cryptographic keys, eliminating the need for redundant, incompatible key management processes. Key lifecycle management—including the generation, submission, retrieval, and deletion of cryptographic keys—is enabled by the standard. Designed for use by both legacy and new cryptographic applications, KMIP supports many kinds of cryptographic objects, including symmetric keys, asymmetric keys, digital certificates, and authentication tokens."

Jon Oltsik, Principal Analyst at the Enterprise Strategy Group: "The challenge of administering multiple data security systems has become more widespread as new technologies with built-in encryption gain acceptance. KMIP can succeed, not only because of the breadth of devices it supports, but also because of the very clear rules it imposes on methods of key management communication'..."

Robert Griffin of EMC/RSA, co-chair of the OASIS KMIP Technical Committee: "KMIP enables a new generation of enterprise key management, fully interoperable across the broad range of cryptographic capabilities that are required for effective security. KMIP's approval as an OASIS Standard represents a milestone for all enterprises that are concerned with the security of their information, identities, and infrastructure." Subhash Sankuratripati of NetApp, co-chair of the OASIS KMIP notes that "Development of KMIP was enriched by participation from across the public and private sectors; in addition to having most of the major software and security vendors involved, government agencies including U.S. NIST and NSA, and large end users, including Aetna and Target, also contributed" to the technical work.

See also: KMIP references

Web Accessibility Initiative (WAI): New and Improved WCAG 2.0 Techniques
Shawn Henry, Blog

"W3C WAI has published updated specifications for Techniques for WCAG 2.0 and Understanding WCAG 2.0, following a public review and comment period. The WCAG Working Group is developing more techniques and would like your help.

Web Content Accessibility Guidelines (WCAG) 2.0 is a W3C standard that is designed to be stable and relevant even as technology changes. One of the benefits of WCAG 2.0 over WCAG 1.0 and other accessibility standards is that 2.0 applies to more advanced technologies, including current, future, and non-W3C technologies. WCAG 2.0 is broadly applicable and technology independent.

Detailed guidance, including technology-specific guidance, on meeting WCAG 2.0 is provided in these supporting documents: (1) 'Techniques for WCAG 2.0', providing guidance for developers with general and technology-specific examples, including for HTML/XHTML, CSS, scripting, multimedia, Flash, and WAI-ARIA; (2) 'Understanding WCAG 2.0', which documents the intent of the guideline or success criterion; how it helps people with different disabilities, browser and assistive technology support notes, examples, and resources.

These supporting documents are designed to be expanded and updated periodically to cover current practices and technologies. The first publication of these supporting documents covered the sufficient techniques and other basics, although they did not document all known techniques (some were marked as 'future link') nor cover all technologies. Today's publication demonstrates WAI's commitment to update the WCAG 2.0 supporting documents..."

NIST Releases Smart Grid Standards
Elizabeth Montalbano, InformationWeek

"The National Institute of Standards and Technology's interoperability and security standards are ready for adoption by federal and state energy regulators. NIST has identified five sets of foundational standards for smart grid interoperability and cybersecurity, furthering the administration's plan for a next-generation, nationwide utility grid.

NIST told the Federal Energy Regulatory Commission (FERC) that the standards —which deal with information models and protocols for reliable and secure grid operations—are now available for consideration and adoption by federal and state energy regulators. Together, the next sets of NIST standards are part of efforts identified in the FERC's Smart Grid Policy Statement, released in July 2010. While NIST is coordinating the development of smart grid standards, the FERC is in charge of policy to ensure adoption of them.

Two of the sets of newly defined standards (IEC 61970 and IEC 61969) provide what is called a Common Information Model (CIM), which is necessary for exchanging data between devices and networks. IEC 61970 works in the transmission domain, while IEC 61969 works in the distribution domain. CIM standards are integral to the deployment of a smart grid scenario, in which many devices connect to a single network. Two other sets of standards, IEC 61850 and IEC 60870-6, also deal with communication and information exchange. The former facilitates substation automation and communication, as well as interoperability through a common data format, while the latter facilitates information exchange between control centers. The fifth set of standards, IEC 62351, defines cybersecurity for the communication protocols defined by the previous four sets.

According to the announcement, "The Energy Independence and Security Act (EISA) of 2007 directed NIST to coordinate development of communication protocols and other standards to achieve an interoperable Smart Grid—a nationwide electric power system that enables two-way flows of energy and information. Under EISA, once it determines sufficient consensus has been achieved, FERC is charged with instituting rulemaking proceedings to adopt the standards necessary to ensure Smart Grid functionality and interoperability..."

See also: the NIST announcement

W3C Invites Implementations of CSS Style Attributes Specification
Tantek Çelik and Elika Etemad (eds), W3C Technical Report

The W3C Cascading Style Sheets (CSS) Working Group now invites implementation feedback on the Candidate Recommendation of the CSS Style Attributes specification. A CSS Style Attributes Test Suite will be developed during the Candidate Recommendation phase of this CSS Style Attributes specification. Changes since the last Working Draft there is a list with the Disposition of Comments.

Markup languages such as HTML and SVG provide a style attribute on most elements, to hold inline style information that applies to those elements. One of the possible style sheet languages is CSS. This draft describes the syntax and interpretation of the CSS fragment that can be used in such style attributes.

The declarations in a style attribute apply to the element to which the attribute belongs. In the cascade, these declarations are considered to have author origin and a specificity higher than any selector. CSS 2.1 defines how style sheets and style attributes are cascaded together. Relative URLs in the style data must be resolved relative to the style attribute's element (or to the document if per-element resolution is not defined) when the attribute's value is parsed. Aside from the differences in cascading, the declarations in a style attribute must be interpreted exactly as if they were given in a CSS style rule that applies to the element...

For this specification to exit the Candidate Recommendation stage, the following conditions shall be met: (1) There must be at least two interoperable implementations. For the purposes of this criterion, 'interoperable' means passing the respective test case(s) in the CSS test suite, or, if the implementation is not a Web browser, an equivalent test. Every relevant test in the test suite should have an equivalent test created if such a user agent (UA) is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publicly available for the purposes of peer review. And 'implementation' refers to a user agent which: implements the specification, is available (i.e. publicly downloadable or available through some other public point of sale mechanism), and is shipped, or is a "nightly build" (i.e., a development version for the next release) but is not experimental; (2) A minimum of one month of the CR period must elapse. That is, this specification will not exit CR before 14 November 2010. When the specification exits CR, an implementation report will be published. At this point, no such report exists..."

Sieve Notification Using Presence Information
Robins George and Barry Leiba (eds), IETF Internet Draft

Members of the IETF Sieve Mail Filtering Language (SIEVE) Working Group have published a Standards Track specification Sieve Notification Using Presence Information. This specification defines a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the 'notify_method_capability' feature.

"Sieve: An Email Filtering Language" describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs.

From the document 'Introduction' section: "Sometimes, it is desirable to tailor Sieve notifications (per RFC 5228) to a user's current situation. Presence information provides some information about the user that would be useful to have access to in these cases. The Notification extension in IETF RFC 5435 defines a mechanism to test for presence (the notify_method_capability feature), and defines one test for presence (the 'online' notification-capability, described in Section 5 of RFC 5435). This extension specifies testing of a wider variety of presence information... This document defines a set of items of notification presence, which may be specified in the notification-capability parameter. The script tests the values of notification presence items in the key-list parameter.

Supported presence items include the following: (1) busy: an indication of whether the user is considered 'busy' now (the value 'yes') or not (the value 'no'), or 'unknown' if it cannot be determined. The meaning of 'busy' is left to the implementation, and may be a state that's synthesized from other information (including 'show', below). (2) show - The availability status of the user, formally specified. Note that this is similar to the presence element with the same name as defined in Section 2.2.2.1 of RFC 3921, where value of this item is one of the following: [away - the user is temporarily away; chat - The user is online and actively interested in chatting; dnd - Do Not Disturb; the user should not be disturbed now; offline - The user is offline; xa - The user is away for an extended period (eXtended Away; unknown - The correct presence value could not be determined]. (3) status: a human-readable description of the user's availability status...."

Survey: Cloud Benefits Not Clearly Defined
Keith Ward, Application Development Trends

"A recent survey shows that one of the greatest challenges facing the adoption of cloud computing is that the industry isn't selling it very well. Integration platform company Hubspan conducted the survey, which found that 59 percent of companies see the cloud as a strategic direction. Twenty percent said they had no interest in the cloud, while 21 percent remain undecided. At the department level, 64 percent are developing plans for the cloud, and a quarter aren't."

According to the Hubspan announcement: "The survey also showed that security, management and scalability are the top considerations for companies when evaluating whether or not to deploy cloud solutions, with 70% citing the ability to secure data as their top priority. Other high scoring considerations include the ability to quickly integrate with internal applications and external partner systems as well as a 'pay as you go' pricing model.

More than 200 companies completed the cloud survey, ranging in size from under 50 to several thousand employees. Respondents represented a range of industries, with high-tech, manufacturing, wholesale distribution, retail and B2B eCommerce accounting for 50% of the polls.

Lack of clarity around cloud benefits was the top reason cited by respondents for not currently implementing cloud-based solutions. Despite the growing adoption of cloud-based solutions, companies still struggle to understand what the cloud is and how to use it..."

The Atom Audience Extension
Will Norris (ed), IETF Internet Draft

An initial level -00 'work in progress' Internet Draft for The Atom Audience Extension has been published in the IETF archives. This extension is related to the Atom Syndication Format specification (IETF Request for Comments 4287).

As proposed in the extension, the 'atom:to' element may be used as the child of an 'atom:entry' element to identify an intended redistribution target for the 'atom:entry'. The value of the 'atom:to' element must be an IRI. Processors that are redistributing copies of an 'atom:entry', should not remove any contained 'atom:to' elements from the redistributed copy. An 'atom:entry' element may contain any number of 'atom:to' elements, but must not contain more than one with the same IRI value as sibling 'atom:to', 'atom:cc', and 'atom:bcc' elements. The value '*' may be used to indicate that the entry is intended to be redistributed to everyone. Processors that encounter IRI values in 'atom:to' elements that cannot be resolved to a entity to which the 'atom:entry' can be redistributed must not stop processing the entry. However, such processors may signal an error or a warning to the client indicating that the IRI is being ignored. The 'atom:cc' element may be used as the child of an 'atom:entry' element to identify an intended redistribution target for the 'atom:entry.' The value of the 'atom:cc' element must be an IRI. Processors that are redistributing copies of an 'atom:entry', should not remove any contained 'atom:cc' elements from the redistributed copy.

The atom:bcc element may be used as the child of an 'atom:entry' element to identify an intended redistribution target for the 'atom: entry'. The value of the 'atom:to' element must be an IRI. Processors that are redistributing copies of an 'atom:entry', must remove all contained 'atom:bcc' elements from the redistributed copy. When redistributing an 'atom:entry' containing 'atom:bcc' elements, the processor may include an empty 'atom:bcc' element within the redistributed copy as an indication to recipients that copies have been sent to an undisclosed set of recipients. An 'atom:entry' element may contain any number of 'atom:bcc' elements, but must not contain more than one with the same IRI value as sibling 'atom:to', 'atom:cc' or 'atom:bcc' elements. Processors must ignore 'atom:bcc' elements that use the reserved '*' value. Processors that encounter IRI values in 'atom:bcc' elements that cannot be resolved to a entity to which the 'atom:entry' can be redistributed must not stop processing the entry. However, such processors may signal an error or a warning to the client indicating that the IRI is being ignored...

The 'atom:to' and 'atom:bcc' elements use IRIs, per RFC 3987. Every URI is also an IRI, so a URI may be used as the value of these elements. When an IRI that is not also a URI is given for dereferencing, it must be mapped to a URI using the steps in Section 3.1 of RFC 3987. The 'atom:to' and 'atom:bcc' elements may have an 'xml:base' attribute. When 'xml:base' is used, it serves the function described in section 5.1.1 of RFC 3986, establishing the base URI (or IRI) for resolving any relative references found within the effective scope of the 'xml:base' attribute..." Discussion of the draft proposal may be found on the atom-syntax mailing list.

See also: Atom references


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

Headlines

Sponsors