Atom Activity Extensions (Draft)

This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft.

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.”

Abstract

This document presents an extension that allows activities on social objects to be expressed within the Atom Syndication Format.

Requirements Language

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 (, “RFC 2119,” .) [RFC2119].

1. Introduction
2. Notational Conventions
3. Activity Concepts
    3.1. Verbs and Object Types
4. Activity Entries
    4.1. Activity Title, Summary and Detail
    4.2. Time of the Activity
    4.3. Activity Link
    4.4. Activity Verb
    4.5. Activity Object
        4.5.1. The activity:object-type Extension Element
    4.6. Activity Target
    4.7. Activity Actor
    4.8. Activity Context
5. Object Entries
    5.1. Implied Activity
        5.1.1. The verbs for the Implied Activity
    5.2. Object Entries in RSS
6. Activity Feeds
    6.1. Feed Subject
        6.1.1. Example
    6.2. A Note about Legacy Feeds
7. The 'post' Verb
8. Requirements for Activity Re-publishers
9. Security Considerations
10. IANA Considerations
11. Normative References
Appendix A. Acknowledgements
Appendix B. Examples
    B.1. Activity Entry Examples
    B.2. Object Entry Example
§ Authors' Addresses

1. Introduction

2. Notational Conventions

The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML elements and attributes described in this specification is: http://activitystrea.ms/spec/1.0/.

In this document, this namespace is referred to as "the AtomActivity namespace", and the namespace prefix "activity:" is used for the above namespace URI. The namespace prefix "atom:" is used for the namespace URI http://www.w3.org/2005/Atom. The choices of namespace prefix are arbitrary and not semantically significant.

This specification uses a shorthand form of terms from the XML Infoset [W3C.REC-xml-infoset-20040204]. The phrase "Information Item" is omitted when naming element and attribute information items. Therefore, when this specification uses the term "element," it is referring to an element information item in infoset terms. Likewise, when this specification uses the term "attribute," it is referring to an attribute information item.

This specification allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also an IRI, so a URI may be used wherever an IRI is named. 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 [RFC3987]. When an IRI is serving as an identifier, it MUST NOT be so mapped.

The text of this specification provides the sole definition of conformance. Examples in this specification are non-normative.

3. Activity Concepts

For the purpose of this specification, an activity is a description of an action that was performed (the verb) at some instant in time by some actor (the actor, as described in Section 4.7 (Activity Actor) ), with some social object (the object). An activity feed is a feed of such activities.

An activity may also have a target, which is the object into which or to which the action was done. Whether a target is allowed and the specific meaning of a target is defined by each verb.

It is expected that in many cases consumers of activity feeds will use them to turn machine readable descriptions of activities into human-readable sentences such as "Joanne posted a Photo: 'My Cat'". The process for forming such sentences is not defined by this specification.

3.1. Verbs and Object Types

Other specifications MAY define further verb and object types with corresponding IRIs. Such specifications MUST define the meaning of these verb and object identifiers, and SHOULD also describe how any additional properties of the verb or object type are to be encoded in an Atom entry.

Verbs and object types MAY derive from other verbs and object types. The properties required by the parents will also be required by the derived types. For example, if there is a base object type image and a derived type of photo, all properties that are defined for image are also defined for photo. Consumers that do not support the photo object type may use their recognition of the image object type as a fallback when processing an object of type photo.

4. Activity Entries

An activity entry is an entry element as described by the Atom specification that represents an activity. The actor of the activity entry is the author of the entry. The verbs and object of the activity are identified explicitly in the Activity entry as described in the following sections. An Atom entry is considered to be an activity entry if and only if it has at least one activity:verb child element and one or more activity:object child elements as described in the following sections.

4.1. Activity Title, Summary and Detail

In an activity entry, the atom:title, atom:summary and atom:content elements as described by [RFC4287] (, “The Atom Syndication Format,” .) MUST contain a human-readable description of the activity. This text will be used by general Atom processors that do not understand this extension. This text MAY also be used by feed processors that do not recognize the verb. Any other non-activity elements may be used in an activity entry to effect a desired handling by non-activity processors.

Feed producers MAY use information from outside sources to choose a suitable language to use for the activity description. For example, a feed producer responding to an HTTP request might use the HTTP Accept-Language header or a user preference otherwise determined to select a language. Feed producers SHOULD use xml:lang as described in [RFC4287] (, “The Atom Syndication Format,” .) section 2 to identify the language used.

4.2. Time of the Activity

The time at which an activity occurred is represented in the atom:published element within each activity entry. An activity entry MUST have exactly one atom:published element.

The time stored herein is the time that the activity occurred, not the time that the associated activity object was published. Feed processors MAY use this element to sort a list of activity entries into chronological order.

4.3. Activity Link

An activity entry SHOULD include an atom:link element with a link relationship of "alternate", a type of "text/html" and a href attribute containing the URL of an HTML-based representation of this activity or the associated object. Though this link does not have any special significance in this specification, general Atom processors that do not support the activity extensions will often present such a link to the user.

4.4. Activity Verb

Verbs are represented using the activity:verb Extension Element. All activity entries MUST have at least one activity:verb element.

The content of the activity:verb element MUST be a verb identifier (an IRI as defined by [RFC3987] (, “Internationalized Resource Identifiers (IRIs),” .)). Note that the definition of IRI excludes relative references. Although the IRI MAY use a dereferencable scheme, processors must not assume that it can be dereferenced.

The verb identifier within this element defines a verb for this activity. A given activity entry MAY have more than one activity:verb element, which indicates that there are several verbs describing this activity. Where multiple verbs are used, all verbs MUST be generalizations or specializations of one another. For example, the general verb "to experience" might be specialized by a verb "to listen to". If a derived verb is used, publishers SHOULD also include all of its ancestor types so that a consumer may use the most specific verb it understands.

An activity feed processor SHOULD use the most specific verb it understands within each entry. If none of the activity's verbs are understood by the processor, the processor MAY use other information to infer the verb, or the processor MAY use the content of the atom:title, atom:summary and/or atom:content to obtain a human-readable description of the activity as a fallback.

<entry>
<id>tag:versioncentral.example.org,2009:/commit/1643245</id>
<published>2009-06-01T12:54:00Z</published>
<title>Geraldine committed a change to yate</title>
<content type="xhtml">Geraldine just committed a change to yate on VersionCentral</content>
<link rel="alternate" type="text/html"
      href="http://versioncentral.example.org/geraldine/yate/commit/1643245" />
<activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
<activity:verb>http://versioncentral.example.org/activity/commit</activity:verb>
<activity:object>
  <activity:object-type>http://versioncentral.example.org/activity/changeset</activity:object-type>
  <id>tag:versioncentral.example.org,2009:/change/1643245</id>
  <title>Punctuation Changeset</title>
  <summary>Fixing punctuation because it makes it more readable.</summary>
  <link rel="alternate" type="text/html" href="..." />
</activity:object>
</entry>

Example: This example introduces a "changeset" object type and a "commit" verb, both ficticious, invented for the ficticious example service "VersionCentral". Since the "commit" verb is a derived type of "post", VersionCentral's activity entries include both the "post" verb and the "commit" verb so that consumers which do not support their proprietary extension may fall back on the "post" verb.

4.5. Activity Object

The object is represented using the activity:object extension element. The activity:object element contains information about the main object of the activity. All activity entries MUST have one or more activity:object elements. The content model of activity:object is identical to that of atom:entry when used in an object entry as described in Section 5 (Object Entries).

activity:object MUST contain exactly one atom:id element. If this object is also published in an object entry, the atom:id value MUST be the same as in the object entry.

activity:object SHOULD contain exactly one atom:title element, which MAY be used by feed processors to identify the object to the user -- for example as the text of a link to the HTML representation of the object.

activity:object SHOULD also contain exactly one atom:link element with a link relationship of "alternate" and the type "text/html", with the href attribute containing the URL of the HTML representation of the object if available.

activity:object MAY also contain an atom:source element, as described by the Atom specification, describing the object feed where this object resides, if any. Processors MAY use this information to give context to the activity. For example, if the source feed has a title of "Claire's Weblog", a processor may include the text "in Claire's Weblog" at the end of a sentence describing the activity to the user.

All other elements included in activity:object SHOULD reflect elements in the object entry for this Object, if one exists.

An activity entry and its associated object entry MUST NOT share the same atom:id value.

An activity entry with more than one activity:object element is considered, for the purposes of activity processing, to be equivalent in meaning to a sequence of activity entries each with a single activity:object and the same verb, actor, target and context. Activity processors SHOULD handle multi-object activities as distinct activities, though they MAY perform any coalescing of activities they deem appropriate when displaying activity data to users. Feed producers MUST NOT create coalesced activity entries except where the rules in this paragraph hold. Coalesced activity entries hold no special meaning to activity processors and are supported only for the benefit of non-activity feed consumers which are not capable of doing any automatic coalescing.

4.5.1. The activity:object-type Extension Element

The content of the activity:object-type element MUST be an object identifier (an IRI as defined by [RFC3987] (, “Internationalized Resource Identifiers (IRIs),” .)). The definition of IRI excludes relative references. Though the IRI MAY use a dereferenceable scheme, processors MUST not assume that it can be dereferenced.

The object identifier within this element gives an object type for the object described by this object entry. A given object entry MAY have more than one activity:object-type element, which indicates that this object has several types. Where multiple types are used, all types MUST be generalizations or specializations of one another. For example, the general type "web page" might be specialized by a type "weblog entry". If a derived type is used, publishers SHOULD also include all of its ancestor types so that a consumer may use the most specific type it understands.

Activity feed processors SHOULD use the most specific object type that they understand within each entry. The processor MAY use other information to infer the object type if it cannot understand any of the object types given. If it cannot so infer the object type, a processor MUST act as though no activity:object-type element is present.

If no activity:object-type element is present, the object has no specific type. Processors SHOULD refer to such objects only by their titles. For example, when forming an activity sentence a processor might say "Johan posted 'My Cat'" rather than "Johan posted a photo: 'My Cat'".

4.6. Activity Target

The activity:target element contains information about the target of the activity, for verbs that support a target. The target is the object that the action was done to. The content model of activity:target and the meaning of its child elements are identical to that of activity:object. The precise meaning of the target as relates to the activity depends on the verb in use, but its meaning is somewhat similar to the English preposition "to". The activity:target extension element MUST NOT be used for indirect objects that are not targets.

4.7. Activity Actor

The activity:actor element MAY be used to describe the object that performed the activity. This element, if present, MUST describe the same object as is described by the atom:author element. The content model and the meaning of its child elements are identical to that of activity:object

In a feed which has an activity:subject element, the activity:actor element MAY be omitted from one or more activity entries, in which case the actor is implied to be the subject of the feed. If the feed has no subject, activity:actor MUST be present.

4.8. Activity Context

The activity:context element is a container for additional contextual information about an activity. This information will often be orthogonal to the verb and object type and supply additional information about the situation in which the activity was performed. For example, an activity entry could contain information about the actor's location at the time of the activity.

5. Object Entries

An object entry is an entry element as described by the Atom specification that represents the object of an activity. Any entry that does not meet the criteria for being an activity entry as described in Section 4 (Activity Entries) is considered an object entry by this specification. In particular, this means that valid Atom entries without any activity annotations are considered to be object entries by this specification.

Object entries are intended to be used by feeds that describe the creation of content. In a valid object entry, all Atom elements SHOULD describe the object that was created or otherwise the object of an activity, rather than describing the activity itself.

The content model of an object entry is the same as that of an activity:object element used within an activity entry, as defined in Section 4.5 (Activity Object).

5.1. Implied Activity

When used alone, outside of the context of an explicit activity entry, an object entry has an implied activity. The implied activity entry for an object entry is constructed as follows:

If the resulting entry will be published, processors SHOULD generate suitable values for all other elements that the Atom specification requires as children of atom:entry. In particular, an atom:id value SHOULD be generated; this value MUST NOT be the same as that of the object entry's atom:id.

If the resulting entry is to be published, processors MAY omit elements from the generated activity:object element to reduce overhead. Such processors SHOULD bear in mind the requirements in Section 4.5 (Activity Object).

Processors expecting activity entries SHOULD apply the above transformation to any object entries they encounter in order to process them as activities, or at least act as if they have done so.

Due to the way it is constructed, there is no way to represent additional properties for the verb(s) of an implied activity. If a particular verb requires additional properties then it MUST NOT be used in an implied activity.

5.1.1. The verbs for the Implied Activity

When appearing as a child of an object entry (that is, an entry that does not also have an activity:object child element), the content of the activity:verb element MUST be the verb type of the implied activity for the object entry, as defined in Section 5.1 (Implied Activity). When used in this way, the content model is identical to when used in an activity entry as described in Section 4.4 (Activity Verb).

5.2. Object Entries in RSS

TODO: this "alternate representation" section should appear after the full description of the "normal" Atom representation.

Objects published as RSS 2.0 item elements MAY use the activity:verb and activity:object-type elements with equivalent content models and semantics as described above for their use in Atom object entries.

Activity processors MUST use the following process to construct the implied activity for an object entry published as an RSS 2.0 item element, or MUST act as if they have done so:

If the above procedure results in an activity entry that is not valid as per this specification or the Atom specification, processors MUST treat the result as they would had the invalid entry arrived in a real feed rather than having been synthesized.

6. Activity Feeds

This specification defines no required extensions to the atom:feed element as defined by the Atom specification. Therefore a standard Atom feed that contains only activity entries as defined above can be considered to be an activity feed. Processors MAY create an activity entry representing the implied post activity of an object entry (see Section 5.1 (Implied Activity)) in order to synthesize an activity feed from a traditional Atom feed.

6.1. Feed Subject

The activity:subject extension element, when used as a child of an atom:feed element, gives information about the object that the feed is describing. An atom:feed element MUST have zero or one activity:subject elements.

The content model of the activity:subject element is the same as that of the activity:object element as described in Section 4.5 (Activity Object).

When the activity:subject extension element is used, the value of its atom:id element can be compared with the corresponding atom:id elements in activity:object, activity:actor and activity:target entry-level elements to determine which role the feed's actor played in an activity. Publishers MAY, when using activity:subject, publish activities in which the feed subject is the object or target rather than the actor; consumers MUST NOT assume that the subject of an activity feed is the actor in all of its constituent activities.

If no activity:subject element is provided then the feed has no subject. Consumers MAY make use of information obtained from another source to determine the subject.

activity:object, activity:target and activity:actor elements which share the same id as the feed's activity:subject SHOULD include only the atom:id element; consumers MUST use the elements of the activity:subject element in place of the elements of the referring element. This minimizes duplication of information in a feed that is about a single subject.

activity:subject MAY be used as a child of any element where feed-level elements are expected, including atom:source. When used in this way, its relationship to the parent element is the same as that of other feed-level elements appearing as its sibling elements.

6.1.1. Example

<feed xml:lang="en-US"
      xmlns:activity="http://activitystrea.ms/spec/1.0/"
      xmlns="http://www.w3.org/2005/Atom">
  <title type="text">Recent activities from Geraldine at PhotoPanic</title>
  <id>tag:photopanic.example.com,2009:user/4859568/activities</id>
  <updated>2009-06-24T03:46:14Z</updated>
  <author>
    <name>Geraldine</name>
  </author>
  <activity:subject>
    <id>tag:photopanic.example.com,2009:/Person/4859568</id>
    <title>Geraldine</title>
    <activity:object-type>http://activitystrea.ms/schema/1.0/person</activity:object-type>
    <link rel="alternate" type="text/html" href="/geraldine" />
  </activity:subject>
.
.
.
</feed>

Example: If we present an atom activity feed which contain all of the photos that Geraldine has uploaded to PhotoPanic then PhotoPanic may publish a feed that begins as illustrated.

6.2. A Note about Legacy Feeds

The implied post activity as described in Section 5.1 (Implied Activity), along with the advice about untyped object entries in Section 5 (Object Entries), are together intended to provide a mechanism for processing traditional non-activity Atom feeds as Activity Feeds. At the time of writing this specification, most such feeds serve to describe the activity of posting an item such as a weblog entry or a photo.

It is acknowledged, however, that there exist feeds that have other meanings, such as a list of a particular user's "favorite" objects. When applying the advice for processing feeds without activity extensions to such feeds, a processor will likely misinterpret the nature of the activity. In practice, however, it seems that most feeds of this kind include something in the title indicating their nature, so rendering such a misinterpreted activity to a sentence will lead to something such as Joe posted "Funny Cats" in "Joe's Favorite Videos", which, while not ideal, is an acceptable result in situations where activities are primarily for human consumption.

7. The 'post' Verb

This specification defines a single verb, which has the verb Identifier IRI http://activitystrea.ms/schema/1.0/post.

This verb describes the act of posting or publishing an object on the web. The implication is that before this activity occurred the object was not posted, and after the activity has occurred it is posted or published.

This verb is used when creating the Implied post activity for a standalone object entry that has no explicit verb. It MAY also be used as the value of activity:verb in an explicit activity entry.

In an activity entry which has the 'post' verb, the value of the atom:published element SHOULD be the same as the atom:published element in the associated object entry.

If an activity using this verb has an activity:target element, the target object is the collection in which the item was posted.

8. Requirements for Activity Re-publishers

An activity re-publisher is any system that produces feeds that contain activities or objects that were obtained from another feed or feed-like data source. This section contains requirements for such systems that aim to allow consumers of such feeds to process the activities described in such feeds in a way similar to how they would have processed the activities when obtained directly from the source, and to allow consumers to detect duplicate activities or objects obtained via multiple feeds.

An activity re-publisher may choose to produce either object entries or Activity Entries, except where the the re-publisher is re-publishing an activity entry, in which case the activity entry MUST be produced to avoid loss of information that cannot be expressed in an object entry.

Where a re-publisher produces a full activity entry from a source object entry, the mapping process described in Section 5.1 (Implied Activity) MUST be used. A re-publisher MAY perform additional mapping steps when doing this conversion.

Where a re-publisher produces a full activity entry from a source RSS object entry, the mapping process described in Section 5.2 (Object Entries in RSS) MUST be used. A re-publisher MAY perform additional mapping steps when doing this conversion.

If a source object entry does not contain verb or object type information, a re-publisher MAY use information obtained elsewhere to synthesize appropriate verb or object type annotations.

When a re-publisher reproduces a source activity entry, the publisher MUST copy the atom:id and atom:published elements from the source activity entry without modification, and MUST similarly preserve the contents of all elements in the AtomActivity namespace where these elements are used correctly as per this specification.

When a re-publisher reproduces an entry, the atom:source element MUST be used in accordance with its definition in the Atom specification. A re-publisher SHOULD include as much information as possible from the source entry, paying special attention to data that is of significance to the object type(s) and/or verb(s) used on the entry where these are known to the re-publisher.

When a re-publisher produces a feed of activities aggregated from multiple sources but known via some externally-obtained information to be by the same actor, even if that actor is represented by a different object in different source feeds, the re-publisher SHOULD create a feed-level activity:subject element that describes the re-publisher's representation of the actor and then substitute this representation in any activity:actor, activity:object or activity:target element known to represent the same actor.

9. Security Considerations

10. IANA Considerations

11. Normative References

Appendix A. Acknowledgements

Appendix B. Examples

This appendix is non-normative. Where these examples include fragments of XML documents, assume the namespace declarations xmlns="http://www.w3.org/2005/Atom" xmlns:activity="http://activitystrea.ms/spec/1.0/" are in scope.

B.1. Activity Entry Examples

<entry>
   <id>tag:photopanic.example.com,2008:activity01</id>
   <title>Geraldine posted a Photo on PhotoPanic</title>
   <published>2008-11-02T15:29:00Z</published>
   <link rel="alternate" type="text/html"
         href="/geraldine/activities/1" />
   <activity:verb>
      http://activitystrea.ms/schema/1.0/post
   </activity:verb>
   <activity:object>
      <id>tag:photopanic.example.com,2008:photo01</id>
      <title>My Cat</title>
      <published>2008-11-02T15:29:00Z</published>
      <link rel="alternate" type="text/html"
            href="/geraldine/photos/1" />
      <activity:object-type>
          tag:atomactivity.example.com,2008:photo
      </activity:object-type>
      <source>
          <title>Geraldine's Photos</title>
          <link rel="self" type="application/atom+xml"
                href="/geraldine/photofeed.xml" />
          <link rel="alternate" type="text/html"
                href="/geraldine/" />
      </source>
   </activity:object>
   <content type="html">
       &lt;p&gt;Geraldine posted a Photo on PhotoPanic&lt;/p&gt;
       &lt;img src="/geraldine/photo1.jpg"&gt;
   </content>
</entry>

This example shows a typical activity entry using the post verb defined by this specification and a hypothetical "photo" object type. It also demonstrates the use of atom:title and atom:content to provide fallback content for feed processors that do not support activity extensions. An activity stream application might render this entry into the sentence "Geraldine posted a photo titled 'My Cat' in Geraldine's Photos", with the photo title and the source feed title presented as links.

<entry>
    <id>tag:photopanic.example.com,2009:/activity/4859568/PhotoAdd/2519358/2009171</id>
    <title type="text">Geraldine added two new photos to the My Pets album.</title>
    <published>2009-06-21T00:28:35Z</published>
    <author>
      <name>Geraldine</name>
      <uri>http://photopanic.example.com/</uri>
    </author>
    <link rel="alternate" type="text/html"
          href="/geraldine/activities/1234" />
    <content type="xhtml">...</content>
    <activity:actor>
      <activity:object-type>http://activitystrea.ms/schema/1.0/person</activity:object-type>
      <id>tag:photopanic.example.com,2009:/Person/4859568</id>
      <title>Geraldine</title>
      <link rel="alternate" type="text/html"
            href="/geraldine" />
    </activity:actor>
    <activity:target>
      <activity:object-type>http://activitystrea.ms/schema/1.0/photo-album</activity:object-type>
      <id>tag:photopanic.example.com,2009:/Photo_Album/2519358</id>
      <title>My Pets</title>
      <link rel="alternate" type="text/html"
            href="/geraldine/albums/pets" />
    </activity:target>
    <activity:object>
      <activity:object-type>http://activitystrea.ms/schema/1.0/photo</activity:object-type>
      <activity:object-type>http://activitystrea.ms/schema/1.0/image</activity:object-type>
      <id>tag:photopanic.example.com,2009:/Photo/2519358/60764840</id>
      <title>My Cat</title>
      <link rel="alternate" type="text/html"
            href="/geraldine/photos/1643" />
      <link rel="preview" type="image/jpeg"
            href="/geraldine/photos/1643/thumb.jpg" />
      <link rel="enclosure" type="image/jpeg"
            href="/geraldine/photos/1643/full.jpg" />
    </activity:object>
    <activity:object>
      <activity:object-type>http://activitystrea.ms/schema/1.0/image</activity:object-type>
      <activity:object-type>http://activitystrea.ms/schema/1.0/photo</activity:object-type>
      <id>tag:photopanic.example.com,2009:/Photo/2519358/60764844</id>
      <title></title>
      <link rel="alternate" type="text/html"
            href="/geraldine/photos/1634" />
      <link rel="preview" type="image/jpeg"
            href="/geraldine/photos/1634/thumb.jpg" />
      <link rel="enclosure" type="image/jpeg"
            href="/geraldine/photos/1634/full.jpg" />
    </activity:object>
</entry>

Example: An activity entry showing the use of the actor, verb, object and target elements. Also illustrated is the use of multiple objects in a single activity entry, which serves as a shorthand for publishing multiple consecutive activities with the same verb and target.

B.2. Object Entry Example

This example shows an object entry describing the object referred to in the activity from Appendix B.1 (Activity Entry Examples). That example would also be an acceptable implied post activity for this entry, assuming that this entry were in a feed whose attributes match those of the atom:source in the activity entry example.

[RFC2119]	“RFC 2119.”
[RFC3339]	Klyne, G., “Date and Time on the Internet: Timestamps,” July 2002.
[RFC3987]	“Internationalized Resource Identifiers (IRIs).”
[RFC4287]	“The Atom Syndication Format.”
[RSS_2.0]	Klyne, G., “Date and Time on the Internet: Timestamps,” July 2002.

	Martin Atkins
	Six Apart

	David Recordon
	Facebook

	Chris Messina
	Diso Project

	Monica Keller
	MySpace

	Ari Steinberg
	Facebook

	Rob Dolin
	Microsoft

Atom Activity Extensions (Draft)
atomactivity-00

Status of this Memo

Abstract

Requirements Language

Table of Contents

1. Introduction

2. Notational Conventions

3. Activity Concepts

3.1. Verbs and Object Types

4. Activity Entries

4.1. Activity Title, Summary and Detail

4.2. Time of the Activity

4.3. Activity Link

4.4. Activity Verb

4.5. Activity Object

4.5.1. The activity:object-type Extension Element

4.6. Activity Target

4.7. Activity Actor

4.8. Activity Context

5. Object Entries

5.1. Implied Activity

5.1.1. The verbs for the Implied Activity

5.2. Object Entries in RSS

6. Activity Feeds

6.1. Feed Subject

6.1.1. Example

6.2. A Note about Legacy Feeds

7. The 'post' Verb

8. Requirements for Activity Re-publishers

9. Security Considerations

10. IANA Considerations

11. Normative References

Appendix A. Acknowledgements

Appendix B. Examples

B.1. Activity Entry Examples

B.2. Object Entry Example

Authors' Addresses

Atom Activity Extensions (Draft)atomactivity-00

Status of this Memo

Abstract

Requirements Language

Table of Contents

1. Introduction

2. Notational Conventions

3. Activity Concepts

3.1. Verbs and Object Types

4. Activity Entries

4.1. Activity Title, Summary and Detail

4.2. Time of the Activity

4.3. Activity Link

4.4. Activity Verb

4.5. Activity Object

4.5.1. The activity:object-type Extension Element

4.6. Activity Target

4.7. Activity Actor

4.8. Activity Context

5. Object Entries

5.1. Implied Activity

5.1.1. The verbs for the Implied Activity

5.2. Object Entries in RSS

6. Activity Feeds

6.1. Feed Subject

6.1.1. Example

6.2. A Note about Legacy Feeds

7. The 'post' Verb

8. Requirements for Activity Re-publishers

9. Security Considerations

10. IANA Considerations

11. Normative References

Appendix A. Acknowledgements

Appendix B. Examples

B.1. Activity Entry Examples

B.2. Object Entry Example

Authors' Addresses

Atom Activity Extensions (Draft)
atomactivity-00