Cover Pages: XML Daily Newslink: Thursday, 08 January 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

SIP Interface to VoiceXML Media Services
Cloud Computing Standards: Deploying and Scaling Services Without Lock-In
Amazon Releases Web-based EC2 Console
Draft Atom-related Specifications for Activity Streams
Representing Rich Media and Social Network Activities in RSS/Atom Feeds
Considerations for Civic Addresses in PIDF-LO: Guidelines and IANA Registry Definition

SIP Interface to VoiceXML Media Services
Dave Burke and Mark Scott (eds), IETF Internet Draft

VoiceXML is a World Wide Web Consortium (W3C) standard for creating audio and video dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of audio and video, telephony, and mixed initiative conversations. VoiceXML allows Web-based development and content delivery paradigms to be used with interactive video and voice response applications. Session Initiation Protocol (SIP) as defined in (RFC 3261 is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. This document describes a SIP interface to VoiceXML media services. Commonly, application servers controlling media servers use this protocol for pure VoiceXML processing capabilities. SIP is responsible for initiating a media session to the VoiceXML media server and simultaneously triggering the execution of a specified VoiceXML application. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. The interface described here leverages a mechanism for identifying dialog media services first described in (RFC 4240). The interface has been updated and extended to support the W3C Recommendation for VoiceXML 2.0 and VoiceXML 2.1. A set of commonly implemented functions and extensions have been specified including VoiceXML dialog preparation, outbound calling, video media support, and transfers. VoiceXML session variable mappings have been defined for SIP with an extensible mechanism for passing application-specific values into the VoiceXML application. Mechanisms for returning data to the Application Server have also been added.

See also: VoiceXML Version 2.0

Cloud Computing Standards: Deploying and Scaling Services Without Lock-In
Daniel Rubio, Web Services Advisor

The software as a service approach already has a series of bodies dedicated to ensuring services themselves are interoperable amongst one another. There is the World Wide Web consortium (W3C) which oversees standards like XML and WSDL, as well as OASIS which sets the course for WS-* standards. Initiatives like these have helped mitigate the risk for both customers and vendors, encouraging the software as a service paradigm since applications are not locked into a particular technology. However, until recently there was one area related to service applications that was unaddressed, one having to do with deploying and scaling services. Once the hurdle of having software enabled as a service is crossed, application interoperability becomes a non-issue, but what happens once a software service is incapable of handling demand with its initial hardware provisions? This inevitably takes us to the analysis of data center infrastructure—or hosting providers. Even for non-service designs, deploying and scaling applications beyond their initial stage is a process which often entails a mix of both hardware and software technology, requiring everything from virtualized operating systems and clustered middleware products to load balancers and custom application modifications, all to accommodate increasing demand. In the software as a service model, rolling out this type of infrastructure may be prohibitive for all but the biggest organizations. But providers have emerged that allow the smallest of organizations to expand application capacity on an as-needed basis, under the utility model of 'pay as you use'. Some of these providers include Amazon's EC2 service and Google's App engine service, as well as specialized software products by companies like 3Tera, RightScale and Elastra, to name a few. And its herein that lies the importance of standardization in the areas of deployment and scalability for cloud computing. A software service might gain from all the standards developed to ensure application inter-operability, but as soon as it attempts to gain deployment and scalability features, provider lock-in occurs...

Amazon Releases Web-based EC2 Console
James Urquhar, CNST News.com

Mike Culver, technology evangelist for Amazon Web Services, has announced the availability of a Web-based AWS management console... This is not really a surprise, as the AWS team indicated that it would release such a console in an earlier announcement. At the time, I pointed out that this was interesting territory for Amazon, as it would, for the first time compete with some of the formal and informal partners that helped drive EC2's popularity. Culver himself gave a shout-out to the popular Elasticfox console, which has been available for some time. Ylastic and others have also provided consoled and management tools for some or all of the AWS platform in the last several months. All are now in competition with their target platform provider... From the announcement: "For starters, it's easier than ever to gain access to your Amazon EC2 environment. The console provides access via your Amazon username and password. No more certificates or public/secret keys to manage! If you're like me, I never seem to have my own computer at hand when I need to check the status of the Amazon EC2 farm, or for that matter when I need to launch a new instance. It's a lot easier to log in with a username and password than to use those same credentials to retrieve my keys, configure Firefox (if it's even on the borrowed computer) and then log in. Then there's the new point-and-click AJAX user interface for managing Amazon EC2 resources. No more page refreshes every time something updates; and a timer refreshes management console components, such as the status of running instances, every few seconds... This is just the first in a set of Console interfaces that will provide a UI layer on top of AWS infrastructure services. We'll be adding additional Amazon Web Services in the future. The console feature list is extensive, and provides intuitive management of all these things: (1) AMI Management: browse and search AMIs, launch instances from AMIs, deregister and register AMIs; (2) Instance Management: launch, reboot, terminate, get console output, RDP/SSH help, etc.; (3) Security Group Management: create and delete security groups, add and remove permissions, configure firewall settings, open and close ports; (4) Elastic IP Management: create and release IP Addresses, associate IPs to instances; (5) Elastic Block Store: create, delete, attach and detach volumes. Take snapshots and manage snapshots; (6) Key Pair management: create and delete public/private key pairs...

See also: Cloud-computing and trust

Draft Atom-related Specifications for Activity Streams
Martin Atkins, Atom-Syntax List Posting

A small group of which I'm a member has been working on a specification for describing activities as Atom entries. An "activity" for our purposes is an action a user has taken on a social website, such as posting a photo or marking it as a favorite. The draft we have so far is "Atom Activity Extensions". In the process of working this through, we discovered a number of other problems that we believe require Atom extensions to solve, so we've also got drafts of a number of peripheral specifications. As Sam Ruby posted earlier in the month, one issue encountered was the lack of a standard way to publish media items such as photos and videos in Atom. While a couple of publishers (notably Google properties) use the elements from MediaRSS for this purpose, the few implementations I found were inconsistent. It was suggested that a more Atom-shaped media specification might be useful, so we drafted up "Atom Media Extensions." We also have a small specification for describing the "service provider" that hosts a feed (for example, YouTube or Twitter). This is intended to be similar in design to 'atom:author', as presented in "Atom and RSS Service Provider Extensions." Finally, we have a small extension to Atom Threading Extensions to allow some metadata about the parent entry to be included in the child so that consumers can avoid fetching source feeds in certain cases. This is intended to be similar in principle to 'atom:source'; see the draft "Atom Comment Metadata Extensions." I'm well aware that these drafts need plenty more editorial work, and may need more detail in certain spots, but since some folks are ready to start implementing based on these drafts I wanted to throw them out here to get a few more eyes on them, so that if there are any major problems with the technical direction we're taking we might fix them before there are too many implementations to change. I would appreciate it if folks here would cast a critical eye over what we're proposing and let me know if you see fundamental flaws in our approach to any of these problems. We will of course continue to refine these documents and hopefully we would be able to bring some or all of them over here and work on them with the wider Atom community.

See also: Atom Activity Extensions

Representing Rich Media and Social Network Activities in RSS/Atom Feeds
Dare Obasanjo, Blog

As I've mentioned previously, one of the features we shipped in the most recent release of Windows Live is the ability to import your activities from photo sharing sites like Flickr and PhotoBucket or even blog posts from a regular RSS/Atom feed onto your Windows Live profile. You can see this in action on my Windows Live profile. One question that has repeatedly come up for our service and others like it, is how users can get a great experience from just importing RSS/Atom feeds of sites that we don't support in a first class way. A couple of weeks ago Dave Winer asked this of FriendFeed in his post FriendFeed and level playing fields: "Suppose you used a photo site that wasn't one of the ones listed, but you had an RSS feed for your photos and favorites on that site. What are you supposed to do? I always assumed you should just add the feed under 'Blog' but then your readers will start asking why your pictures don't do all the neat things that happen automatically with Flickr, Picasa, SmugMug or Zooomr sites. I have such a site, and I don't want them to do anything special for it, I just want to tell FF that it's a photo site and have all the cool special goodies they have for Flickr kick in automatically..." We have a similar problem when importing arbitrary RSS/Atom feeds onto a user's profile in Windows Live. For now, we treat each imported RSS feed as a blog entry and assume it has a title and a body that can be used as a summary. This breaks down if you are someone like Kevin Radcliffe who would like to import his Picasa Web albums. At this point we run smack-dab into the fact that there aren't actually consistent standards around how to represent photo albums from photo sharing sites in Atom/RSS feeds... As you can see from the XML snippets, there is no consistency in how they represent photo streams. Even though both Picasa and Zoomr use Yahoo's Media RSS extensions, they generate different markup. The bottom line is that it isn't possible to satisfy Dave Winer's request and create a level playing field today because there are no consistently applied standards for representing photo streams in RSS/Atom. So far, the closest thing to a standard in this space is Media RSS but as the name states it is an RSS based format and really doesn't fit with the Atom syndication format's data model. This is why Martin Atkins has started working on Atom Media Extensions which is an effort to create a similar set of media extensions for the Atom syndication format. What I like about the first draft of Atom media extensions is that it is focused on the basic case of syndicating audio, video and image for use in activity streams and doesn't have some of the search related and feed republishing baggage you see in related formats like Media RSS or iTunes RSS extensions.

See also: Atom references

Considerations for Civic Addresses in PIDF-LO: Guidelines and IANA Registry Definition
Karl Heinz Wolf and Alexander Mayrhofer, IETF Internet Draft

This document provides a guideline for creating civic address consideration documents for individual countries, as required by IETF RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address consideration documents. The "Presence Information Data Format Location Object" (PIDF-LO) (RFC 4119) is an object format for carrying geographical information on the Internet, including an XML representation. PIDF-LO can be used to convey civic address information, and supports a range of "civic address types". In many use cases, PIDF-LOs are populated with data from long-established sources, like postal or governmental building registers, line information databases and yellow / white pages of infrastructure providers, or official residents registers. The structure and format of data from such sources is almost always different from PIDF-LO's CAtypes definition—additionally, structure and format of those sources differs from country to country. To make use of such existing data sources, transposing that data into PIDF-LO format is required. With no guidelines available on how to map source Fields into CAtype Elements, different creators of PIDF-LO documents might end up with different results, even when using the same data source—which reduces interopability and increases the risk of misinterpretation by receivers. Therefore, civic address considerations are necessary to ensure uniform usage of PIDF-LO Elements for such data sources. RFC 4776 explicitly requests such documents to be provided, but does neither define their structure nor a way to publish them. This memo provides documentation on how to create such civic addresses...


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

Headlines

Sponsors