Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
A Powerbox facilitates the creation of links between customer content and resources hosted at Web sites or on the user's Web browsing device, including resources created on-the-fly from device sensors. By using the Powerbox, customer content can request access to a user's private resources, regardless of where those resources reside or how they are created.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is for review by the Device APIs Working Group and is subject to change without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This section is non-normative.
Today's users have a great variety of private resources beyond the files stored on their local computing device. Web sites maintain user collections of photos, email, contact information, documents, videos and other types of content. In addition to static content, these sites also offer interactive resources such as discussion forums and event planning. A great variety of such sites exist and ever more are created. Today's computing devices are also typically equiped with many sensors, such as a camera, microphone, geolocation and even physical orientation of the device. These sensors enable quick creation of new resources. In such a resource rich environment, a particular resource might want to support linking and interaction with other resources without being tightly coupled to where these resources are hosted or how they are produced. To meet this need, we introduce a mechanism that enables:
Other specifications define how customer content then interacts with the provided resource. For example, the mechanism defined here can be used to connect customer content to an AtomPub service which can then be interacted with according to [RFC 5023]. For some resources, such as blogs, existing specifications, such as RFC 5023, might be sufficient to enable a complete interaction between customer content and provided resources. For other kinds of resources, new specifications might be needed to determine how customer content interacts with a provided resource. The Powerbox addresses the orthogonal problems of how customer content discovers what resource to interact with and how the user grants permission for this interaction.
Using the Powerbox, customer content can acquire a link to a resource in a uniform way, independent of where the resource is hosted or how it is created. The resource might be created on-the-fly from local sensors, such as the camera, or hosted at a web site, such as a photo sharing site. Similarly, a resource host or creator can offer its resources in a way that makes them readily accessible from customer content. To maintain privacy and security, this facilitated exchange of links between providers and customers remains under the control and direction of the user.
This specification is written for resource authors and user-agents.
As well as sections and appendices marked as non-normative, all diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
In this specification, the terms MUST and MUST NOT are to be interpreted as described in [RFC2119].
A conformant resource is one that implements all the requirements listed in this specification that are applicable to resources.
A conformant user-agent is one that implements all the requirements listed in this specification that are applicable to user-agents.
This section provides an overview of the interaction model and definitions of the various actors and artifacts involved in these interactions.
Figure 1: The Powerbox intermediates a requisition from a Customer page to a user selected Provider. The Customer page can then directly send HTTP requests to the provided resource.
We aim to facilitate user directed introduction of resources to customer
content. Customer content makes a requisition for a described resource. A resource is
described using the mechanism defined for the [HTTP]
Accept header. A Provider is a resource
that can satisfy a requisition by
providing a link to a provided resource. A Provider might declare that it can only
satisfy requests for resources also described using the [HTTP] Accept mechanism. A Powerbox is the part of a user-agent that mediates
introductions of provided resources to Customers. In response to a requisition, the Powerbox presents the user with a choice of Providers that can satisfy the request. The Powerbox forwards the requisition to the user selected Provider. To provide a resource, the Provider responds with either a link to the provided resource or a link to a Chooser page for choosing or configuring the provided resource. The Chooser page is presented to the user, but is not made
accessible to the Customer content. The Chooser page provides the Powerbox a link to the provided resource. If a Provider requires no user interaction to satisfy a requisition, it can directly return a link
to the provided resource.
When performing an introduction, a Powerbox only forwards a provided resource link to a Customer, and does not provide the Customer a link to the user selected Provider. A user's list of Providers is confidential information to be withheld from Customers. The Powerbox does not prevent a Provider resource from subsequently choosing to reveal itself in response to a Customer request to the provided resource.
It is expected that many Providers will be coarse grained, acting as a gateway to a great number of resources. For example, a given Provider might provide all user accessible resources at a particular Web site. Once selected for a particular requisition, a Provider can use the resource description and user interaction to choose among the Provider's resources. Although there might exist a great number of Providers, it is expected that any particular user will only register a small subset of offered Providers with their Powerbox. Consequently, the list of Providers a Powerbox presents to a user is expected to be relatively short. To keep this list short, a fine grained Provider should declare a tight description of resources it can provide. This declaration enables the Powerbox to omit listing the Provider for requisitions the Provider cannot satisfy.
Presented content interacts with a user-agent's Powerbox via an object accessed from the read-only
powerbox attribute of the Window object. The Powerbox object has the following
interface:
// Application interface to the Powerbox. interfacePowerbox{ // Make a requisition. // // This method is invoked by a Customer page. // // The callback will be invoked with the request return value. void request(inRequisitionrequisition, in Function callback); // Satisfy a previous request invocation. // // This method is invoked by a Chooser page. void provide(in any provided); }; // Details about a requisition. interfaceRequisition{ // MIME media type filters, ordered from most preferred to least // // This filter describes the MIME media type used by the response // to aGETrequest to the provided resource. // // If undefined, assume any MIME media type is acceptable. attributeAccept[] wanted; // Customer's reason for the request attribute DOMString reason; // additional information to be delivered to the provided resource, // or used by a Chooser page // // The payload expected by a provided resource is determined // by the specification of thewantedMIME type. In general, // a Customer should assume that no payload is expected. // // Future revisions of this specification might define new // attributes for theRequisitioninterface. To avoid naming // conflicts, use the payload attribute for any application // specific data. attribute any payload; }; // A parsed filter of accepted MIME media types. interfaceAccept{ // MIME media type // // If undefined, assume "*". attribute DOMString type; // MIME media subtype // // If undefined, assume "*". attribute DOMString subtype; // name to value mapping of accept-extensions // // If undefined, assume there are no extensions. attribute object extensions; };
A Provider is offered for registration with a Powerbox by [HTML] content
including either a <link> or <a> element
with a type attribute of
application/org.w3.powerbox.Provider+json and an href
attribute declaring the Provider URL. The
user-agent MUST provide a presentation of this offer that enables the user to request registration of the Provider, unless it is already registered. URI
equivalence on the Provider URL, using
any of the techniques defined in [RFC3986], can be used
to determine if an offered Provider is the same as a registered one. A registered Provider
is one which the Powerbox remembers until
explicitly instructed otherwise.
For example, a web page offers a Provider with content like:
<link rel="alternate" type="application/org.w3.powerbox.Provider+json"
title="My Example Account" href="/mystuff/?s=phawbhhasdf">
The user-agent annotates the web page with an icon indicating a pending offer. If the user clicks on this icon, the Provider URL is added to the Powerbox's list of registered Providers.
Alternatively, a web page offers a Provider with content like:
<a type="application/org.w3.powerbox.Provider+json" href="/mystuff/?s=phawbhhasdf">Register your My Example Account Provider</a>
If the user clicks on the hyperlink, the Powerbox asks the user if the Provider should be registered.
A Powerbox obtains metadata for a Provider by making a uniform request [UMP] to the Provider URL with
method GET. The Provider MUST return [JSON] text for an object that
has the attributes defined by the Provider interface:
// Metadata about a Provider. interfaceProvider{ // short name attribute DOMString title; // longer description attribute DOMString description; // declaration of supported resources // // This filter describes the MIME media type used by the // response to aGETrequest to a provided resource. // // If undefined, assume all MIME media types are supported. attributeAccept[] supports; // where to send requisitions attributeLinkrequest; // additional user interface for the Provider // // The referenced page might provide a history of // requisitions handled by this Provider. attributeLinkhome; }; // A reference. // // This type identifies a URL string that MUST be resolved // relative to a base URL. interfaceLink{ // URL for the linked to resource attribute DOMString '@'; };
For example, a GET request to the Provider URL
"https://provider.example.com/mystuff/?s=phawbhhasdf" might return:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/org.w3.powerbox.Provider+json
Cache-Control: max-age=604800
{
"title" : "My Example Account",
"description" : "All resources in your Example account.",
"supports" : [ { "type" : "*", "subtype" : "*" } ],
"request" : { "@" : "requests/?s=ruwsdslowefh" },
"home" : { "@" : "home/#s=hhaweoibfhb" }
}
The URL provided by a Link MUST be resolved relative to the request URI, as is the convention
for relative URLs in an [HTTP] response.
For example, the request URL in the previous
example resolves to:
https://provider.example.com/mystuff/requests/?s=ruwsdslowefh
Customer content makes a requisition for a resource by invoking the Powerbox.request
method.
For example, a requisition for an audio clip is expressed as:
window.powerbox.request({
wanted: [ { type: 'audio' } ],
reason: 'Greeting for your profile page'
},
function (provided) {
// play the identified audio clip
});
In response to a requisition, the Powerbox MUST enable user
selection of any registered Provider that can satisfy the request. A Provider can satisfy a request if there exists
a media type that satisfies at least one of the Accept entries in the wanted argument of the requisition, and at least one of the Accept entries in the supports declaration
made in the Provider Document. Whether or
not a given media type satisfies an Accept entry is determined by the same rules
used by the Accept header in [HTTP].
For example, the following table lists Provider filtering decisions for a given requisition and a given Provider Document.
wanted |
supports |
can satisfy? |
|---|---|---|
| audio/* | audio/mpeg, audio/mp4 | yes |
| audio/* | audio/* | yes |
| audio/* | */* | yes |
| audio/mpeg | audio/mpeg, audio/mp4 | yes |
| audio/mpeg | audio/* | yes |
| audio/mpeg | */* | yes |
| audio/mpeg | undefined | yes |
| audio/mpeg, audio/mp4 | audio/mpeg | yes |
undefined | audio/mpeg | yes |
| audio/* | image/jpeg, image/tiff | no |
| audio/* | image/* | no |
When filtering Providers for a requisition, the Powerbox can use a stale Provider Document, but should try to keep a valid cache. A Provider MUST NOT rely on its Provider Document being refreshed more than once a day.
In response to a requisition, a Powerbox can list other Providers in addition to registered ones, but MUST enable the user to distinguish between registered and non-registered Providers.
If a Provider is selected for a requisition, the Powerbox forwards the request to the selected Provider. This introduction request MUST be a uniform request [UMP] to the request URL declared in the Provider Document, with method
POST. The body of the introduction request MUST be the [JSON] text for an object that has the attributes defined
by the Introduction
interface:
// Body of an introduction request. // // Future revisions of this specification might extend this interface with // additional attributes determined by the Powerbox and not by the Customer. interfaceIntroduction{ // ASCII serialization of the Customer's origin attribute DOMString customer; // Customer's requisition attributeRequisitionrequisition; };
The customer attribute of an introduction MUST be the
ASCII serialization of the [origin] of the Customer content that made the corresponding
Powerbox.request
invocation. The requisition attribute of
an introduction MUST
be the requisition argument
of the corresponding Powerbox.request invocation.
For example, the previous example requisition produces an introduction request like:
POST /mystuff/requests/?s=ruwsdslowefh HTTP/1.1
Host: provider.example.com
Content-Type: text/plain; charset="UTF-8"
{
"customer" : "https://customer.example.org",
"requisition" : {
"wanted" : [ { "type" : "audio" } ],
"reason" : "Greeting for your profile page"
}
}
To provide a resource, a Provider MUST respond to an introduction with a 200-level uniform response [UMP] with an entity body of [JSON]
text for an object that has attributes defined by the Provision interface:
// An introduction response. interfaceProvision{ // requisition return value, orundefinedif not known yet attribute any provided; // Chooser page, orundefinedif no further user interaction is needed attributeLinkchooser; };
If provided is
defined, the Powerbox MUST invoke the requisition's callback with the
corresponding value, after resolving any relative URL in response Link objects. Note that the provided value can
be an arbitrarily deep nested structure of [JSON] values
with embeded Link objects.
Each of these Link URLs MUST be resolved relative to the request URI before invoking the
requisition's callback. If chooser is defined,
the Powerbox MUST present
the referenced resource. If neither provided nor chooser is defined, the Powerbox MUST invoke the requisition's callback with an
undefined argument.
A Customer and Provider coordinate the expected requisition return value using the Requisition's wanted attribute. For MIME
types that do not specify Powerbox
interaction parameters, the requisition
return value is expected to be an object with attributes defined by the
Anchor interface:
// The default return type for a Powerbox.request invocation. // // MIME types that specify additional data to be returned from a requisition // are encouraged to extend this interface with additional attributes. interfaceAnchor{ // negotiated MIME media type of the content available athrefattributeAccepttype; // link to a provided resource attributeLinkhref; };
For example, for an interactive introduction, a Provider might return a response like:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
{
"chooser" : { "@" : "chooser/#s=chhuwaefb" }
}
The Powerbox opens a new browser tab on the URL:
https://provider.example.com/mystuff/requests/chooser/#s=chhuwaefb
For a non-interactive introduction, a Provider might return a response like:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
{
"provided" : {
"type" : { "type" : "audio", "subtype" : "mpeg" },
"href" : { "@" : "/clips/1234.mpeg" }
}
}
The Powerbox invokes the requisition's callback with an Anchor for the URL:
https://provider.example.com/clips/1234.mpeg
If the Provider is unable to provide an appropriate resource for the requisition, it might return a response like:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
{
"provided" : { "!" : "no audio clips uploaded to this account yet" }
}
For an interactive introduction, a
Provider responds with a link to a Chooser page. Once that page is
ready to satisfy the requisition, it
invokes the Powerbox.provide method. The Powerbox MUST in turn invoke
the corresponding requisition's
callback
with a [JSON] value equivalent to the provided
argument.
For example, a Chooser page might contain an invocation like:
window.powerbox.provide({
type: { type: 'audio', subtype: 'mpeg' },
href: { '@': 'https://provider.example.com/clips/5678.mpeg' }
});
In response to this invocation, the Powerbox forwards the provided argument to the
corresponding requisition's callback:
var pendingCallback;
function provide(value) {
pendingCallback(JSON.parse(JSON.stringify(value)));
}
Once a Customer page has received a provided resource URL, it can use this URL with any API supported by the user-agent.
For example, Customer content might
assign a provided resource URL to an
<img>'s src attribute, or initiate an
XMLHttpRequest operation.
This section is non-normative.
This section offers advice to resource authors.
The Powerbox is a general purpose mechanism for introducing Customer content to new and potentially private resources. New types of resources can be made accessible to Web content by using the Powerbox for discovery and introduction, existing user-agent APIs such as XMLHttpRequest for interaction, existing MIME media types for syntax, and HTTP methods for general semantics. In some cases, new MIME media types may need to be defined to coordinate custom interaction patterns, but otherwise, these techniques should often be sufficient to Web-enable a wide variety of hardware and software artifacts.
The Powerbox uses MIME media types to
coordinate: the expected value of any Requisition.payload argument;
the expected return value of the Powerbox.request(); and the MIME
media type of a response to a GET request to any provided resource. For example, a requisition for an AtomPub service might be coordinated
using the MIME media type "application/atomsvc+xml" where: no Requisition.payload is
expected; the corresponding Powerbox.request() return value is
an Anchor; and the provided resource is an AtomPub Service
Document. New specifications might define new MIME media types to coordinate
other values for these parameters for interacting with other kinds of
resources. When making a requisition for
a MIME media type that does not specify any Powerbox interaction parameters, the Customer should assume that no Requisition.payload argument is
expected and the return value of the Powerbox.request() invocation is
an Anchor to the provided resource.
When deciding how to represent some computer artifact as a collection of resources, aiming for a finer granularity can often make access control issues more easily solved. For example, in the Examples section of this document, a design for making a computer's microphone accessible to Web content is presented. Rather than representing the microphone as a single resource to which Web content might be granted access, the presented design instead represents the microphone as a sequence of short-lived sound capture events. Instead of getting access to the microphone itself, Web content only gets access to one of these capture events. When the capture event ends, so does all of the Web content's permission to the microphone. Other kinds of artifacts can similarly be subdivided into fine grained resources that match the granularity of typical user interaction patterns.
When the provided resource is a static
data file, such as in the microphone example, the only
access control issue of whether or not to provide the data to the Customer is handled through the Powerbox introduction. When the provided resource is a long-lived mutable
resource, the issue of revoking the Customer's access to the resource becomes relevant. If the
interaction between the Customer and the provided resource is a one-shot transfer of
information, the difficult issue of revocation can be avoided by transferring
the data via the payload attribute of the Requisition. In this way,
the Customer never receives permission to
directly interact with the provided
resource, so there's no permission to be revoked. For more involved
interaction patterns, dealing with revocation might be inescapable. In this
case, the Provider should keep track of
granted permissions for provided resources
and provide a user interface for reviewing and revoking outstanding permissions.
This user interface should be accessible from the page referred to by the home attribute of the Provider Document.
The author of a Customer page should keep in mind that a provided resource URL might have been determined by a malicious Provider and so refer to a resource owned by the Customer and not by the Provider. To avoid Confused Deputy attacks, the Customer should not include its credentials in requests made using a provided resource URL. Such requests should only be made using an API that conforms to the Uniform Messaging Policy [UMP].
Since a provided resource URL might be an alias for another resource URL, clients should keep in mind the Web's URI opacity good practice and so not infer any properties of the referenced resource based on the content of a provided resource URL. In particular, a provided resource URL might redirect to a completely different URL identifying a resource hosted at a different Web site.
This section is non-normative.
This section offers advice to user-agent authors.
When considering how to respond to a requisition, a user should take into account their
relationship with the Customer who will be
accessing the provided resource. This
consideration is only possible if the user can identify the origin of a requisition. A user-agent should only
present a requisition when the user can
identify the corresponding Customer. For
example, [HTML] supports an <iframe>
element where content from another origin can be presented but where there is
typically no identification of the content's origin. Presenting a requisition from the content of a
cross-origin <iframe> would be misleading for the user since
it appears as if the requisition came
from the top-level page. To guard against this misunderstanding, a user-agent
should not support a requisition made
from an <iframe> whose origin does not match that of the top
level page.
When presenting a requisition, the Powerbox offers the user a menu of Providers to select from. Whether or not to select a Provider, and which one to select, is a decision made by the user. Malicious content might attempt to force the user's hand in this decision using a [clickjacking] attack. A user-agent must protect the Provider selection menu against clickjacking attacks. For example, the user-agent should prevent Customer content from controlling any transparency setting on the Provider selection menu. Malicious content might also try to prime the user to click in the area where a Provider selection menu will soon appear. To guard against this attack, a user-agent might require a different user gesture for selection of a Provider, or impose a "cooling off" timeout before a selection can be made.
This specification uses one new media type that conforms to the registry mechanism described in [RFC4288].
A Provider Document, when serialized as [JSON], can be identified with the following media type:
This appendix is non-normative.
This section illustrates potential uses of the Powerbox in a variety of scenarios.
In this scenario, a Customer receives access to an audio stream from a microphone attached to the user's computer. The Provider is built into the user-agent, instead of being hosted on the Web, so requests to the Provider are directly satisfied by the user-agent, rather than being forwarded to a web server.
To request an audio clip, Customer content makes a requisition like:
window.powerbox.request({
wanted: [ { type: 'audio' } ],
reason: 'Greeting for your profile page'
},
function (provided) {
if (provided && provided.href &&
/^(https?|chrome):/i.test(provided.href['@'])) {
// play the audio clip
var player = document.createElement('embed');
player.setAttribute('src', provided.href['@']);
document.body.appendChild(player);
}
});
In response to this requisition, the Powerbox presents a choice of Providers. The user selects the microphone Provider. The Provider turns on the computer's microphone, which activates a recording status indicator in the user-agent's chrome.
When done recording, the user invokes a "Stop" option from the recording indicator in the user-agent's chrome. The user-agent turns off the computer's microphone, thus terminating the audio stream.
This scenario is the same as the Microphone example, but this time the user selects a remote file store Provider instead of the local computer's microphone Provider.
The Customer content makes the same requisition as before. This time, the Powerbox forwards the request to the selected
remote Provider using the request URL specified in the
corresponding Provider Document:
POST /mystuff/requests/?s=ruwsdslowefh HTTP/1.1
Host: provider.example.com
Content-Type: text/plain; charset="UTF-8"
{
"customer" : "https://customer.example.org",
"requisition" : {
"wanted" : [ { "type" : "audio" } ],
"reason" : "Greeting for your profile page"
}
}
The remote Provider responds with a link to its file chooser:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
{
"chooser" : { "@" : "chooser/#s=cufddfwaefs" }
}
The Powerbox opens a new browser tab on:
https://provider.example.com/mystuff/requests/chooser/#s=cufddfwaefs
In the new browser tab, the user navigates the remote filesystem and eventually chooses a file. The Chooser page invokes:
window.powerbox.provide({
type: { type: 'audio', subtype: 'mpeg' },
href: { '@': 'https://provider.example.com/clips/5678.mpeg' }
});
The Powerbox forwards this invocation to
the requisition's callback.
In this scenario, Customer content provides a customized user interface for generating blog posts on a specific topic. In particular, the Customer content might also have access to a live transcript of an ongoing presentation. The customized user interface facilitates quoting the speaker and linking to the speaker's presentation materials.
To request write access to the user's blog, Customer content makes a requisition like:
window.powerbox.request({
wanted: [ { type: 'application', subtype: 'atomsvc+xml' } ],
reason: 'Live blog the Example conference!'
},
function (provided) {
// Get the AtomPub Service Document.
var xhr = new XMLHttpRequest();
xhr.open('GET', provided.href['@'], true);
…
});
In response to this requisition, the Powerbox presents a choice of the user's blog Providers. The user selects the Provider for their personal blog, which causes the Powerbox to send a request like:
POST /mystuff/requests/?s=ruwsdslowefh HTTP/1.1
Host: provider.example.com
Content-Type: text/plain; charset="UTF-8"
{
"customer" : "https://customer.example.org",
"requisition" : {
"wanted" : [ { "type" : "application", "subtype" : "atomsvc+xml" } ],
"reason" : "Live blog the Example conference!"
}
}
The blog Provider responds with a Chooser page where the user can customize the type of access:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
{
"chooser" : { "@" : "chooser/?s=tuiwefjb" }
}
On the Chooser page, the user chooses "append only" access, meaning the live blogging Customer content should only be able to create new blog entries and not edit existing ones. The Chooser page generates a corresponding URL for use by the live blogging Customer content:
window.powerbox.provide({
type: { type: 'application', subtype: 'atomsvc+xml' },
href: { '@': 'https://provider.example.com/blogs/?s=ldfbhnas' }
});
The Powerbox forwards this Anchor to the Customer's callback, which then
starts creating blog entries.
In this scenario, Customer content receives access to some of the user's inbound SMS messages.
To request a message stream, Customer content makes a requisition like:
window.powerbox.request({
wanted: [ { type: 'text', subtype: 'event-stream' } ],
reason: 'Include messages in your activity log.'
},
function (provided) {
// Use Server-Sent Events (SSE) to receive message notifications.
var source = new EventSource(provided.href['@']);
source.onmessage = function (event) {
// include the received message in the chat window
};
});
In response to this requisition, the Powerbox presents a choice of Providers. The user selects the local device Provider, which responds with an interactive Chooser page. On this page, the user chooses contacts whose SMS messages will be forwarded to the Customer. Whenever a new SMS message arrives and its sender corresponds to one of the contacts chosen by the user, the message is added to the event stream provided to the Customer.
In this scenario, Customer content has information about a scheduled event and updates a user's calendar with this information.
This scenario assumes a future specification not described here that defines
the semantics of a custom calendar Requisition.payload.
To request that an event be added to the user's calendar, Customer content makes a requisition like:
window.powerbox.request({
wanted: [ { type: 'application', subtype: 'FutureCalendar' } ],
payload: {
add: {
summary: 'Working Group telecon',
dtstart: '2010-04-05T22:00:00Z',
dtend: '2010-04-05T23:00:00Z'
}
}
},
function (provided) {
// nothing more to do
});
In response to this requisition, the Powerbox presents a choice of Providers. The user selects the Provider for their Web-based calendar service:
POST /mystuff/requests/?s=ruwsdslowefh HTTP/1.1
Host: provider.example.com
Content-Type: text/plain; charset="UTF-8"
{
"customer" : "https://customer.example.org",
"requisition" : {
"wanted" : [ { "type" : "application", "subtype" : "FutureCalendar" } ],
"payload" : {
"add" : {
"summary" : "Working Group telecon",
"dtstart" : "2010-04-05T22:00:00Z",
"dtend" : "2010-04-05T23:00:00Z"
}
}
}
}
The calendar Provider adds the event to the user's calendar.
This appendix is non-normative.
The editors thank Adam Barth, Anne van Kesteren, Arve Bersvendsen, Bryan Sullivan, Dirk Pranke, Frederick Hirsch, Ian Hickson, Mark Miller, Max Froumentin, Robin Berjon, Thomas Roessler.