| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2010.
This document defines a protocol for activity publishers to push activity notifications directly to an activity consumer. This is in contrast to the traditional feed-based activity publishing model where a consumer pulls activities from the publisher.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
1.
Introduction
2.
Definitions
3.
Submitting an Activity
4.
Integration with OpenID and OAuth
4.1.
Publisher Requests Publishing Access
4.2.
Consumer Returns Endpoint URL
5.
Normative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
...
A design goal of this specification is to be compatible with the OpenSocial activity push mechanism, assuming that OpenSocial has been extended to support Activity Streams properties.
This document is a work in progress. Everything here is just random brainstorming at this point.
| TOC |
- Activity Publisher
- An application that generates activities and transmits them to an activity consumer.
- Activity Consumer
- An application that recieves and processes activities.
- Activity Endpoint
- An HTTP resource provided by an activity consumer to which the publisher submits activities.
| TOC |
Before submitting an activity, the activity publisher must determine the URL of the activity endpoint provided by the activity consumer. The mechanism for doing this is not defined by this specification, but mechanisms may include simply providing the URL of the endpoint in the consumer's human-readable documentation or using the OpenID and OAuth integration described in Section 4 (Integration with OpenID and OAuth).
An activity is submitted from the activity publisher to the activity consumer by submitting an HTTP POST request to the activity endpoint. The entity body of this request is an activity or an activity stream as defined by the activity streams specifications. Consumers MUST accept activities that are expressed in Atom as described in [atomactivity] (Atkins, M., “Atom Activity Extensions,” .), either in the form of an Atom feed or a single top-level Atom entry. When the request body is an Atom feed or Atom entry, the Content-Type header field in the request MUST carry the value application/atom+xml.
A single activity submit request MAY express multiple activities, either by providing a feed containing a list of activities or by providing a single Atom entry which expresses multiple activities by virtue of including multiple objects.
The activity consumer MAY accept any other activity serialization when submitted with an appropriate Content-type.
If the activity consumer accepts the submitted activity, it MUST return an HTTP response with either a 201 Created or 202 Accepted status code. If 201 Created is used, the response MUST include a Location header which gives a URL at which the created activity can be retrieved as required by the HTTP specification. If the request contained multiple activities the consumer MUST return 202 Accepted. The response entity body MUST be a representation with an appropriate Content-Type of the submitted activity or activities as they were understood by the consumer. The consumer SHOULD return this response using the same serialization format that was used in the request.
The activity consumer MAY require authentication credentials to be provided for the request to its activity endpoint. If so, the standard HTTP authentication mechanism SHOULD be used.
If the activity consumer does not accept all of the activities in the request, the consumer MUST return an appropriate HTTP error response and disregard all activities in the request. The consumer MUST either accept or reject the entirety of the request, and not accept some included activities but not others.
The consumer SHOULD apply similar fallback behavior to submitted activities than what would be applied to activities retrieved from a feed, including the fallback behavior defined for unrecognised object types in the Activity Streams specifications.
| TOC |
Although this specification requires no specific mechanism for discovery of the activity submission endpoint URL, this section defines an optional integration with OpenID and OAuth to provide endpoint URL discovery as part of an OpenID transaction. This may be combined with the OpenID/OAuth hybrid extension to also provide authentication credentials to the consumer where necessary.
In this flow, the activity publisher takes the role of OpenID Relying Party while the activity consumer takes the role of OpenID Provider.
This integration takes the form of an OpenID Authentication 2.0 extension. The extension namespace URI for this extension is http://activitystrea.ms/push. The extension alias aspush is used for this extension in the sections that follow, but this is merely a notational convention; the extension alias has no semantic significance.
| TOC |
In order to request activity publishing access, the publisher begins an OpenID Authentication transaction as normal with the activity consumer. The authentication request MUST carry the following additional argument:
- openid.aspush.formats
- A comma-separated list of MIME types which the publisher can use to post activities, in order of preference. This list SHOULD include application/atom+xml.
The request MAY also include the initiation parameters for the OpenID OAuth Extension in order to request an OAuth token that will enable publishing access to the activity endpoint.
The consumer MAY include on the OpenID user approval page a choice for the user about whether to grant publishing access.
| TOC |
If the consumer grants publishing access, the response MUST include the following additional arguments:
- openid.aspush.url
- The URL of the consumer's activity endpoint for the authenticated user.
- openid.aspush.format
- The MIME type in which the provided activity endpoint accepts activities. This MUST be one of the MIME types given in the publisher's request.
If the consumer does not support any of the formats that the publisher indicates support for, the consumer MUST NOT return the above response arguments.
If the response also includes an OAuth token using the OpenID OAuth Extension, either this OAuth token MUST grant activity publishing access to the indicated endpoint or the consumer MUST NOT return the above response arguments.
If the response does not include the above response arguments then either the consumer does not support this extension or it has chosen not to provide access to post activities.
If the above response arguments are included but no OAuth token is issued this does not necessarily imply that activity posting does not require authentication; the credentials necessary to post activities may be issued by some separate mechanism specific to the consumer.
| TOC |
| [atomactivity] | Atkins, M., “Atom Activity Extensions.” |
| TOC |
| Martin Atkins |
| TOC |
Copyright © The IETF Trust (2009).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.