This specification details a model for representing potential and completed activities using the JSON format.

Author's Note

This section is non-normative.

This draft is heavily influenced by the JSON Activity Streams 1.0 specification originally co-authored by Martin Atkins, Will Norris, Chris Messina, Monica Wilkinson, Rob Dolin and James Snell. The author is very thankful for their significant contributions and gladly stands on their shoulders. Some portions of the original text of Activity Streams 1.0 are used in this document.

Status of This Document

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 was published by the Social Web Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-socialweb-comments@w3.org (subscribe, archives). All comments are welcome.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

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 document is governed by the 1 August 2014 W3C Process Document.

Table of Contents

1. Introduction

In the most basic sense, an "activity" is a semantic description of a potential or completed action. In the former case, the activity expresses what can or might be done with a particular object, while in the latter case, it expresses what has already been done.

It is the goal of this specification to provide a JSON-based syntax that is sufficient to express metadata about activities in a rich, human-friendly, machine-processable and extensible manner. This may include constructing natural-language descriptions or visual representations about the activity, associating actionable information with various types of objects, communicating or recording activity logs, or delegation of potential actions to other applications.

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 [RFC2119].

1.1 Relationship to JSON Activity Streams 1.0

This section is non-normative.

The JSON Activity Streams 1.0 [AS1] specification was published in May of 2011 and provided a baseline extensible syntax for the expression of completed activities. This specification builds upon that initial foundation by incorporating lessons learned through extensive implementation, community feedback and related ongoing work from a variety of other communities.

While the syntax defined by this specification diverges somewhat from that defined by JSON Activity Streams 1.0, the verbs, objectTypes, extensions and fundamental model defined by that original specification remain intact, and every valid Activity Streams 1.0 document is a valid Activity Streams 2.0 document.

Please refer to Section 6 for more detail about the differences between the 1.0 and 2.0 syntax and for a listing of specific backwards compatibility requirements.

This specification incorporates several existing extensions to the 1.0 syntax directly into the 2.0 model. These include portions of the Activity Streams 1.0 Base Schema, Audience Targeting, Responses, and Priority extensions.

1.2 Serialization Notes

This specification describes a JSON-based [RFC7159] serialization syntax for the Activity Vocabulary that follows the conventions defined by the [JSON-LD] specification. While serialization forms other than JSON-LD are possible, alternatives are not discussed by this document.

When serialized, absent properties are represented by either (a) setting the property value to null, or (b) by omitting the property declaration altogether at the option of the publisher; these representations are semantically equivalent. If a property has an array value, the absence of any items in that array MUST be represented by omitting the property entirely or by setting the value to null. The appropriate interpretation of an omitted or explicitly null value is that no value has been assigned as opposed to the view that the given value is empty or nil.

This specification uses IRIs [RFC3987]. Every URI [RFC3986] is also an IRI, so a URI may be used wherever an IRI is named. There are two special considerations: (1) 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] and (2) when an IRI is serving as an "id" value, it MUST NOT be so mapped.

Unless otherwise specified, all properties with date and time values MUST conform to the "date-time" production in [RFC3339], with an uppercase "T" character used to separate date and time, and an uppercase "Z" character in the absence of a numeric time zone offset. All such timestamps SHOULD be represented relative to Coordinated Universal Time (UTC).

Activity Streams 2.0 documents MUST be serialized using the UTF-8 character encoding.

2. Examples

This section is non-normative.

Following are three examples of activities with varying degrees of detail. Each of the examples uses an implied JSON-LD @context equal to that provided here.

2.1 Minimal Activity

Fig. 1 Expresses the statement "'urn:example:person:martin' posted 'http://example.org/foo.jpg'". No additional detail is given.
Example 1
  "@type": "http://activitystrea.ms/2.0/Activity",
  "verb": "post",
  "actor": "urn:example:person:martin",
  "object": "http://example.org/foo.jpg"

2.2 Basic activity with some additional detail

Fig. 2 Expresses the statement "Martin Smith posted an article to the blog 'Martin's Blog' at 3:04 PM GMT on February 2, 2011." Some additional details about the article, actor and target blog are given using properties defined by the Activity Streams 2.0 Vocabulary.
Example 2
  "@type": "http://activitystrea.ms/2.0/Activity",
  "language": "en",
  "verb": "post",
  "published": "2011-02-10T15:04:55Z",
  "actor": {
   "@type": "urn:example:types:person",
   "@id": "urn:example:person:martin",
   "displayName": "Martin Smith",
   "url": "http://example.org/martin",
   "image": {
     "@id": "http://example.org/martin/image.jpg",
     "@type": "http://activitystrea.ms/2.0/Link",
     "mediaType": "image/jpeg"
  "object" : {
   "@type": "urn:example:types:article",
   "@id": "urn:example:blog:abc123/xyz",
   "url": "http://example.org/blog/2011/02/entry",
   "displayName": "Why I love Activity Streams"
  "target" : {
   "@type": "urn:example:types:blog",
   "@id": "http://example.org/blog/",
   "displayName": "Martin's Blog"

2.3 An extended activity

Fig. 3 A more extensive, single-entry "Activity Stream" follows.
Example 3
  "@type": "http://activitystrea.ms/2.0/Collection",
  "totalItems": 1,
  "items" : [
      "@type": "http://activitystrea.ms/2.0/Activity",
      "language": "en",
      "verb": "post",
      "published": "2011-02-10T15:04:55Z",
      "generator": "http://example.org/activities-app",
      "provider": "http://example.org/activity-stream",
      "displayName": {
        "en": "Martin posted a new video to his album.",
        "ga": "Martin phost le fisean nua a albam."
      "actor": {
        "@type": "urn:example:types:person",
        "@id": "urn:example:person:martin",
        "displayName": "Martin Smith",
        "url": {
          "@id": "http://example.org/martin",
          "@type": "http://activitystrea.ms/2.0/Link",
          "displayName": "Martin's Profile"
        "image": {
          "@id": "http://example.org/martin/image",
          "@type": [
          "mediaType": "image/jpeg",
          "width": 250,
          "height": 250
      "object" : {
        "@type": "http://example.org/Photo",
        "@id": "http://example.org/album/my_fluffy_cat.jpg",
        "image": {
          "@id": "http://example.org/album/my_fluffy_cat_thumb.jpg",
          "@type": "http://activitystrea.ms/2.0/Link",
          "mediaType": "image/jpeg",
          "rel": "preview"
      "target": {
        "@type": "http://example.org/PhotoAlbum",
        "@id": "http://example.org/album/",
        "displayName": {
          "en": "Martin's Photo Album",
          "ga": "Grianghraif Mairtin"
        "image": {
          "@id": "http://example.org/album/thumbnail.jpg",
          "@type": "http://activitystrea.ms/2.0/Link",
          "mediaType": "image/jpeg"

3. Model

The Activity Vocabulary defines the abstract model for Activity Streams 2.0. The vocabulary document defines seven distinct abstract classes: Object, Link, Collection, Activity, NaturalLanguageValue, Verb, and ObjectType. Each of these classes is described and illustrated below.

3.1 Object

The Object class is the primary base class for the Activity Streams vocabulary. An implementations would typically create it's own set of subclasses that derive from the http://activitystrea.ms/2.0/Object class as opposed to using Object directly.

In addition to having a global identifier in the form of an absolute IRI and an "object type" (expressed in JSON-LD using the @type keyword), all instances of the Object class share a common set of properties as defined by the Activity Vocabulary. These include: action | alias | attachment | author | content | displayName | duration | endTime | generator | height | icon | image | inReplyTo | language | location | memberOf | provider | published | rating | replies | resultOf | scope | startTime | summary | tag | title | updated | validAfter | validBefore | validFrom | validUntil | width | url

While all properties are optional, all Object instances SHOULD at least contain a displayName.

Fig. 4 Following is an example Object that uses the JSON-ID @id and @type JSON-LD keywords to express the global identifier and object type:
Example 4
  "@id": "http://example.org/foo",
  "@type": "http://example.org/types/Note",
  "language": "en",
  "displayName": "This is a note",
  "author": {
    "@id": "urn:example:person:joe",
    "@type": "http://example.org/types/Person",
    "displayName": "Joe Smith"
  "published": "2014-08-21T12:34:56Z"

3.2 Natural Language Values

Several properties defined by the Vocabulary are defined as being a Natural Language Value. These are a representations of human-readable character sequences using one or more languages. Within the JSON-LD serialization, they are expressed as either (1) a single JSON string or (2) a JSON object mapping [RFC5646] Language-Tags to localized, equivalent translations of the same string value. In [JSON-LD], such constructs are referred to as "Language Maps".

For instance, the displayName property is a Natural Language value.

Fig. 5 A single String value using the default language:
Example 5
  "language": "en",
  "displayName": "This is the title"
Fig. 6 Multiple, language-specific values:
Example 6
  "displayName": {
    "en": "This is the title",
    "fr": "C'est le titre",
    "sp": "Este es el titulo"

Every key in the JSON object MUST be an [RFC5646] Language-Tag. The associated values MUST be Strings.

3.2.1 Implementation Note

This section is non-normative.

Implementers ought to note that, in [JSON-LD], establishment of a default language requires the use of the @language keyword inside the JSON-LD @context. For instance:

Fig. 7 Using the @language keyword:
Example 7
  "@context": {
    "@language": "en"
  "displayName": "This is the title"

Using the @language keyword in this manner establishes the default language context for all string literal property values contained by the object, including those that may not be intended as natural language values. This current definition for @language makes it difficult for implementations that choose to ignore JSON-LD semantics when processing Activity Streams documents or that wish to limit the language context only to properties that are truly intended as natural language values. The language property introduced by the Activity Streams Vocabulary is provided to address these shortcomings by allowing a default language to be established independently of the JSON-LD @context.

Fig. 8 Using the language property has the same effect as using the @language inside the JSON-LD @context:
Example 8
  "language": "en",
  "displayName": "This is the title"

However, use of language means that JSON-LD based implementations will need to take an additional processing step to ensure that properties such as title, displayName, summary and content are handled properly.

Fig. 9 For instance, the following example JavaScript function extracts the value of the language property and injects it as an appropriate JSON-LD @language keyword into specific properties that are defined as Natural Language Values to ensure that such properties are properly handled by the standardized JSON-LD algorithms:
Example 9
function _fixdefaultlanguage(lang, obj) {
  var __lang = obj['language'] || lang;
  for (var n in obj) {
    if (nlvs.indexOf(n) > -1) {
      var vals = obj[n];
      vals.forEach(function(val) {
        val['@language'] = val['@language'] || __lang;
    } else if (typeof obj[n] === 'object') {
      var next = exp[n];
      if (!Array.isArray(next)) 
        next = [next];

3.4 Activity

Activity objects are specializations of the base Object type that provide information about ongoing or completed actions.

In additional to common properties supported by all Object instances, Activity objects support the following additional properties defined by the Vocabulary: verb | actor | object | target | result | instrument | participant | priority | status | to | bto | cc | bcc

The verb property is used to identify the type of activity. If the verb is not specified, the @type keyword MAY be used as an alternative means of determining the activity type.

Fig. 15 The following example illustrates a simple Activity:
Example 15
  "@type": "http://activitystrea.ms/2.0/Activity",
  "@id": "urn:example:activity:1",
  "verb": {
    "@id": "urn:example:verb:like",
    "displayName": "like"
  "actor": "http://example.org/profiles/joe",
  "object": "http://example.com/notes/1",
  "published": "2014-09-30T12:34:56Z"

3.4.1 Implementation Note

This section is non-normative.

Since Activity Streams 1.0, the verb property has been defined to permit identifiers either in the form of absolute IRI's or simple isegment-nz-nc tokens. For instance, "post" is a valid Activity Streams verb.

However, existing JSON-LD processing algorithms have difficulty processing such isegment-nz-nc token values properly without additional processing. It is RECOMMENDED that JSON-LD implementations handle simple isegment-nz-nc verbs as "blank nodes". For instance, the value "post" would map to the blank node identified as _:post.

3.4.2 Audience Targeting

Every Activity has both a Primary and Secondary audience. The Primary audience consists of those entities either directly involved in the performance of the activity or who "own" the objects involved. The Secondary audience consists of the collection of entities sharing an interest in the activity but who are not directly involved (e.g. "followers").

For instance, suppose a social network of three individuals: Bob, Joe and Jane. Bob and Joe are each friends with Jane but not friends with one another. Bob has chosen to "follow" activities for which Jane is directly involved. Jane shares a file with Joe.

In this example, Jane and Joe are each directly involved in the file sharing activity and together make up the Primary Audience for that event. Bob, having an interest in activities involving Jane, is the Secondary Audience. Knowing this, a system that produces or consumes the activity can intelligently notify each person of the event.

While there are means, based on the verb, actor, object and target of the activity, to infer the primary audience for many types of activities, those do not work in every case and do not provide a means of identifying the secondary audience. The to, cc, bto and bcc properties MAY be used within an Activity to explicitly identify the Primary and Secondary audiences.

The prototypical use case for an Activity containing these properties is the publication and redistribution of Activities through an intermediary. That is, an event source generates the activity and publishes it to the intermediary which determines a subset of events to display to specific individual users or groups. Such a determination can be made, in part, by identifying the Primary and Secondary Audiences for each activity.

When the event source generates the activity and specifies values for the to and cc fields, the intermediary SHOULD redistribute that event with the values of those fields intact, allowing any processor to see who the activity has been targeted to. This is precisely the same model used by the to and cc fields in email systems.

There are situations, however, in which disclosing the identity of specific members of the audience may be inappropriate. For instance, a user may not wish to let other users know that they are interested in various topics, individuals or types of events. To support this option, an event source generating an activity MAY use the bto and bcc properties to list entities to whom the activity should be privately targeted. When an intermediary receives an activity containing these properties, it MUST remove those values prior to redistributing the activity. The intent is that systems MUST consider entities listed within the bto and bcc< properties as part of the Primary and Secondary audience but MUST NOT disclose that fact to any other party.

Audience targeting information included within an Activity only describes the intent of the activity creator. With clear exception given to the appropriate handling of bto and bcc, this specification leaves it up to implementations to determine how the audience targeting information is used.

3.5 Collection

Collection objects are a specialization of the base Object that contain a listing of other Objects. The Collection object is used primarily as the root of an Activity Streams Document, but can also be used as the value of object properties.

Collections have both a logical model and a physical serialization. While the logical view of a collection might contain a large number of objects, any single serialized representation might include only a subset of those objects, with specific "paging" Links used to reference additional serialized representations that include additional subsets. Such representations are known as "multi-page collections", with each serialized subset representing a single "page".

All Collection objects have an items property whose value is a JSON array of Objects of any type. The items property MUST be supported by all implementations.

In addition to the common properties shared by all Object instances, Collection objects set of properties defined by the Vocabulary. These include: items | totalItems | itemsPerPage | startIndex | itemsAfter | itemsBefore | current | next | prev | first | last | self

Fig. 16 The following is a simple collection with paging:
Example 15
  "@type": "http://activitystrea.ms/2.0/Collection",
  "totalItems": 10,
  "itemsPerPage": 1,
  "itemsSince": "2012-12-12T12:34:56Z",
  "next": "http://example.org/foo?page=2",
  "self": "http://example.org/foo?page=1",
  "items": [
      "actor": "urn:example:person:sally",
      "verb": "post",
      "object": "http://example.org/foo"

3.6 Verbs and Object Types

A Verb is a subclass of Object used to specifically describe metadata associated with an Activity verb identifier.

Fig. 17 For instance, the following describes the "urn:example:verbs:upload" verb identifier:
  "@type": "http://activitystrea.ms/2.0/Verb",
  "@id": "urn:example:verbs:upload",
  "displayName": "Upload",
  "alias": "upload"

Likewise, a ObjectType is a subclass of Object used to describe metadata associated with an Object @type identifier.

Fig. 18 For instance, the following describes the "urn:example:types:note" object type:
  "@type": "http://activitystrea.ms/2.0/ObjectType",
  "@id": "urn:example:types/note",
  "displayName": "Note"

3.7 Potential Actions

Ed.Note: This section is currently provisional and may be moved to a separate document.

All Object instances can have an action property used to describe the kinds of potential activities that can be taken with regards to the object. The value is expressed as a JSON object conforming to the PotentialAction class defined by the Actions Vocabulary.

Fig. 19 For instance, the following illustrates hypothetical object with "urn:example:types:note" as the objectType, and potential actions "urn:example:actions:ShareAction" and "urn:example:actions:SaveAction":
Example 16
  "@type": "urn:example:types:note",
  "@id": "urn:example:notes:1",
  "action": [
      "@type": "urn:example:actions:ShareAction",
      "using": {
        "@type": "http://activitystrea.ms/2.0/HttpRequest",
        "method": "POST",
        "url": "http://example.org/share?id=1"
      "@type": "urn:example:actions:SaveAction",
      "using": {
        "@type": "http://activitystrea.ms/2.0/EmbeddedView",
        "content": "<p>...</p>",
        "mediaType": "text/html"

Please refer to the Actions Vocabulary for more detail on the Potential Actions model.

4. Activity Streams Document

An Activity Streams Document is a JSON-LD document whose root value is a Collection and whose MIME media type is "application/activity+json".

5. Deprecated Activity Streams 1.0 Syntax

The JSON syntax defined by this specification differs somewhat from that defined in the original JSON Activity Streams 1.0 [AS1] specification in ways that are not backwards compatible. Implementations can choose to continue supporting the JSON Activity Streams 1.0 syntax but SHOULD consider it to be deprecated. This means that while implementations MAY continue to consume the 1.0 syntax, they SHOULD NOT output the 1.0 syntax unless specifically interacting with older non-2.0 compliant implementations.


  1. Implementations MUST use the "application/stream+json" MIME media type when producing a JSON serialization using the Activity Streams 1.0 syntax, and "application/activity+json" when producing a serialization conforming to the 2.0 syntax.
  2. Implementations that process serializations identified using either the "application/stream+json" or the more generic "application/json" MIME media type MUST follow the syntax and processing rules set by [AS1]. The 2.0 syntax and processing rules apply only when handling serializations using the "application/activity+json" media type.
  3. Implementations MUST treat the id and objectType properties defined by Activity Streams 1.0 as aliases for the JSON-LD keywords @id and @type, respectively.
  4. This document redefines the displayName, title, content and summary properties as Natural Language Values, which means their values can be expressed as either a String or a JSON-LD Language Map. In the 1.0 syntax, these are expressed solely as String values. Because the 1.0 values are a valid subset allowed by this specification, implementations are not required to take any specific action to continue supporting those values.
  5. This document redefines a large number of common properties defined originally as Objects in 1.0 as either Objects or Links. The JSON-LD serialization allows such property values to be expressed as either an IRI String, an JSON object, or an Array of IRI Strings and JSON objects. Because the 1.0 values are a valid subset allowed by this specification, existing implementations are not required to take any specific action to continue supporting those values.
  6. This specification deprecates the upstreamDuplicates and downstreamDuplicates properties defined by Activity Streams 1.0 and does not provide a replacement. This is due largely to lack of any reasonable implementation evidence. While the upstreamDuplicates and downstreamDuplicates properties MAY continue to be used, implementations SHOULD avoid them.

By following these requirements, all JSON Activity Streams 1.0 serializations can be processed successfully by 2.0 implementations.

6. Extensibility

Processors that encounter unfamiliar property names or values MUST NOT stop processing or signal an error and MUST continue processing the items as if those properties were not present.

6.1 Handling of JSON-ID Compact IRIs

In JSON-LD, a "Compact IRI" is a type of shorthand notation that allows absolute IRI values to be split into an absolute base IRI and a relative token. For instance, in the following example:

Fig. 20
Example 17
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/"
  "foaf:givenName": "Sam"

The property name foaf:givenName is a Compact IRI that expands to "http://xmlns.com/foaf/0.1/givenName" when processed by a JSON-LD implementation.

While there are differences of opinion on how extensively Compact IRIs ought to be used within JSON-LD document instances, JSON-LD implementations are required to support them.

In order to simplify implementation and encourage interoperable reuse, the following predefined prefixes are defined for Activity Streams 2.0 as an "Initial Context":

Prefix Expanded
as: http://activitystrea.ms/2.0/
as1: http://activitystrea.ms/1.0/
dc: http://purl.org/dc/elements/1.1/
dct: http://purl.org/dc/terms/
dctypes: http://purl.org/dc/dcmitype/
foaf: http://xmlns.com/foaf/0.1/
vcard: http://www.w3.org/2006/vcard/ns#
org: http://www.w3.org/ns/org#
prov: http://www.w3.org/ns/prov#
geo: http://www.w3.org/2003/01/geo/wgs84_pos#
geos: http://www.opengis.net/ont/geosparql#

For instance, the property name foaf:givenName would expand to "http://xmlns.com/foaf/0.1/givenName", while the property prov:actingOnBehalfOf would expand to "http://w3.org/ns/prov#actingOnBehalfOf".

7. Security Considerations

Publishers or Consumers implementing Activity Streams as a stream of public data may also want to consider the potential for unsolicited commercial or malicious content and should take preventative measures to recognize such content and either identify it or not include it in their implementations.

Publishers should take reasonable measures to ensure potentially malicious user input such as cross-site scripting attacks are not included in the Activity Streams data they publish.

Consumers that re-emit ingested content to end-users MUST take reasonable measures if emitting ingested content to make sure potentially malicious ingested input is not re-emitted.

Consumers that re-emit ingested content for crawling by search engines should take reasonable measures to limit any use of their site as a Search Engine Optimization loophole. This may include converting untrusted hyperlinks to text or including a rel="nofollow" attribute.

Consumers should be aware of the potential for spoofing attacks where the attacker publishes activities or objects with falsified property values with the intent of injecting malicious content, hiding or corrupting legitimate content, or misleading users.

Activity Streams are JSON Documents and are subject to the same security considerations described in [RFC7159].

Activity Streams implementations handle URIs. See Section 7 of [RFC3986].

Activity Streams implementations handle IRIs. See Section 8 of [RFC3987].

8. IANA Considerations

8.1 The application/activity+json Media Type

This specification registers the application/activity+json MIME Media Type:

Type name: application
Subtype name: activity+json
Required parameters: None
Optional parameters: None
Encoding considerations: Resources that use the "application/activity+json" Media Type are required to conform to all of the requirements for the "application/json" Media Type and are therefore subject to the same encoding considerations specified in Section 11 of [RFC7159].
Security considerations: As defined in this specification.
Contact: James M Snell <jasnell@gmail.com>

A. Acknowledgements

The author wishes to thank the Activity Streams community and implementers for their support, encouragement, and enthusiasm including but not limited to: Abdul Qabiz, Adina Levin, Adrian Chan, Adriana Javier, Alan Hoffman, Alex Kessinger, Alexander Ovchinnikov, Alexander Zhuravlev, Alexandre Loureiro Solleiro, Amy Walgenbach, Andres Vidal, Angel Robert Marquez, Ari Steinberg, Arjan Scherpenisse, Arne Roomann-Kurrik, Beau Lebens, Ben Hedrington, Ben Metcalfe, Ben Werdmuller, Benjamin Goering, Bill de hOra, Bo Xing, Bob Aman, Bob Wyman, Brett Slatkin, Brian Walsh, Brynn Evans, Charlie Cauthen, Chris Chabot, Chris Messina, Chris Toomey, Christian Crumlish, Dan Brickley, Dan Scott, Daniel Chapman, Danny Ayers, Dare Obasanjo, Darren Bounds, David Cramer, David Nelson, David Recordon, DeWitt Clinton, Douglas Pearce, Ed Summers, Elias Bizannes, Elisabeth Norris, Eric Marcoullier, Eric Woods, Evan Prodromou, Gee-Hsien Chuang, Greg Biggers, Gregory Foster, Henry Saputra, Hillary Madsen, Howard Liptzin, Hung Tran, Ian Kennedy, Ian Mulvany, Ivan Pulleyn, Jacob Kim, James Falkner, James Pike, James Walker, Jason Kahn, Jason Kantz, Jeff Kunins, Jeff Martin, Jian Lin, Johannes Ernst, John Panzer, Jon Lebkowsky, Jon Paul Davies, Jonathan Coffman, Jonathan Dugan, Joseph Boyle, Joseph Holsten, Joseph Smarr, Josh Brewer, Jud Valeski, Julien Chaumond, Julien Genestoux, Jyri Engestroem, Kaliya Hamlin, Kevin Marks, Laurent Eschenauer, Laurie Voss, Leah Culver, Libby Miller, Manu Mukerji, Mark Weitzel, Marko Degenkolb, Marshall Kirkpatrick, Martin Atkins, Martin Svensson, Marty Alchin, Mary Hoder, Matt Leventi, Matt Wilkinson, Matthias Mueller-Prove, Max Engel, Max Wegmueller, Melvin Carvalho, Michael Buckbee, Michael Chan, Michael Richardson, Michael Sullivan, Mike Macgirvin, Mislav Marohnić, Mo Jangda, Monica Wilkinson, Nate Benes, NeilFred Picciotto, Nick Howard, Nick Lothian, Nissan Dookeran, Nitya Narasimhan, Pablo Martin, Padraic Brady, Pat Cappelaere, Patrick Aljord, Peter Ferne, Peter Reiser, Peter Saint-Andre, Phil Wolff, Philip (flip) Kromer, Richard Cunningham, Richard Zhao, Rick Severson, Robert Hall, Robert Langbert, Robert Dolin, Robin Cover, Ryan Boyd, Sam Sethi, Scott Raymond, Scott Seely, Simon Grant, Simon Wistow, Stephen Garcia, Stephen Sisk, Stephen Paul Weber, Steve Ivy, Steve Midgley, Steven Livingstone-Perez, Sylvain Carle, Sylvain Hellegouarch, Tantek Çelik, Tatu Saloranta, Tim Moore, Timothy Young, Todd Barnard, Tosh Meston, Tyler Gillies, Will Norris, Zach Copley, Laurent-Walter Goix, Matthew Marum, Andy Smith, and Zach Shepherd.

B. Summary of Changes


C. Table of Figures

D. References

D.1 Normative references

J. Snell; M. Atkins; W. Norris; C. Messina; M. Wilkinson; R. Dolin. JSON Activity Streams 1.0. unofficial. URL: http://activitystrea.ms/specs/json/1.0/
Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 16 September 2014. W3C Proposed Recommendation. URL: http://www.w3.org/TR/html5/
Manu Sporny; Gregg Kellogg; Markus Lanthaler. JSON-LD 1.0. 16 January 2014. W3C Recommendation. URL: http://www.w3.org/TR/json-ld/
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: http://www.ietf.org/rfc/rfc2119.txt
G. Klyne; C. Newman. Date and Time on the Internet: Timestamps. July 2002. Proposed Standard. URL: http://www.ietf.org/rfc/rfc3339.txt
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL: http://www.ietf.org/rfc/rfc3986.txt
M. Duerst; M. Suignard. Internationalized Resource Identifiers (IRIs). January 2005. Proposed Standard. URL: http://www.ietf.org/rfc/rfc3987.txt
M. Nottingham. Web Linking. October 2010. Proposed Standard. URL: http://www.ietf.org/rfc/rfc5988.txt
T. Bray, Ed.. The JavaScript Object Notation (JSON) Data Interchange Format. March 2014. Proposed Standard. URL: http://www.ietf.org/rfc/rfc7159.txt

D.2 Informative references

A. Phillips, Ed.; M. Davis, Ed.. Tags for Identifying Languages. September 2009. Best Current Practice. URL: http://www.ietf.org/rfc/rfc5646.txt