1. Document Status

Authors
Status

Stable Draft

Last Updated

2016-03-20

Proposed IANA Registrations

application/vnd.uber+xml, application/vnd.uber+json

Supported H-Factors

LO, LE, LT, LI, LN, CR, CU, CM, CL

2. General

The UBER document format is a minimal read/write hypermedia type designed to support simple state transfers and ad-hoc hypermedia-based transitions. This specification describes both the XML and JSON variants of the format and provides guidelines for supporting UBER-encoded messages over the HTTP protocol.

2.1. Design Goals

The UBER document model has a number of design goals:

  • Keep the document structure as lean as possible.

  • Support all the H-Factors [HFactor].

  • Be compatible with multiple protocols (e.g. [HTTP], [CoAP], etc.)

  • Maintain fidelity for more than one base document formats (XML, JSON, etc.)

2.2. Messages, Not Code

The UBER document model is designed to be a message format and not a source code format. It is optimized for cross-format use (XML and JSON) and not optimized to be directly serialized into source code or data objects. This is especially noticeable in the JSON variant of UBER. However, the UBER document model is designed to make it relatively easy to write a parser that can consistently transform UBER documents into object models (and back again).

Throughout this specification, we refer to UBER documents, but occasionally we may say: "UBER message", which refers to an UBER document that is being transmitted over a wire protocol. Due to the strongly message-oriented nature of the UBER model, the distinction is typically minor.

2.3. Compliance

An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED elements. An implementation that satisfies all the MUST and REQUIRED elements as well as all the SHOULD and RECOMMENDED elements is said to be "unconditionally compliant"; one that satisfies all the MUST and REQUIRED elements but not all the SHOULD and RECOMMENDED elements is said to be "conditionally compliant."

Note

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

3. The UBER Document Model

The UBER document model is very minimal. The list of elements, properties, and reserved values is rather small in order to keep the process of describing and processing documents as lightweight as possible.

3.1. Elements

Below is the list of all possible elements in an UBER document:

<uber>

The root element of all UBER documents

<data>

The main element in UBER documents.

<error>

The element that carries error details from the previous request.

3.2. Properties

Below is a list of all the possible properties in an UBER document:

id

The document-wide unique identifier for this element.

name

A document-wide non-unique identifier for this element.

rel

Contains one or more link relation values.

label

Contains a string that represents the caption for the value property of the associated data element.

url

A resolvable URL associated with this element. If the value of templated is set to true, the value of url SHOULD be treated as a URI Template.

templated

If set to true the value of the url property contains a URI Template. The default value is false.

action

The network request verb associated with this element.

transclude

Indicates whether the content that is returned from the URL should be embedded within the currently loaded document.

model

Contains a template to be used to construct message bodies.

sending

Contains one or more media type identifiers for use when sending request bodies.

accepting

Contains one or more media type identifiers to expect when receiving request bodies.

value

In the XML variant of the UBER message format, inner text of the <data> element contains the value associated with that element. In the JSON variant there is a value property that contains the associated value.

version

Indicates the UBER document’s version information.

3.3. Reserved Strings

Below is the list of reserved strings used as possible values for UBER properties.

Reserved strings for the templated property

  • true : treat the value of url as a URI Template per [RFC6570]

  • false : treat the value of url as a valid URL per [RFC3986]. [DEFAULT]

Reserved strings for the action property

  • append : An unsafe, non-idempotent request to add a new item.

  • partial : An unsafe, non-idempotent request to modify parts of an existing item.

  • read : A safe, idempotent request. [DEFAULT]

  • remove : An unsafe, idempotent request to delete an existing item.

  • replace : An unsafe, idempotent request to replace an existing item.

Reserved strings for the transclude property

  • true : embed the results of the request into the current document

  • false : treat the associated url value as a navigation to a new document. [DEFAULT]

  • audio : treat the associated url value as an embedded audio resource.

  • image : treat the associated url value as an embedded image resource.

  • text : treat the associated url value as an embedded text resource (e.g. HTML.IFRAME).

  • video : treat the associated url value as an embedded video resource.

3.4. Link Relation Values

There are no UBER-specific link relation values. Document authors SHOULD use registered link relation values that comply the guidance provided in [RFC5988] and from shared public sources such as (but not limited to):

3.5. Document Map

Below is a simple ‘map’ of the UBER document format (XML variant). Along with the three elements, there are 12 properties (indicated by the ‘@’ character). The <data> element can appear as a child element of <uber> and <error> and may be nested as many times as needed.

UBER Document Model (XML)
<uber @version>
  <data @id @name @rel @label @url @templated @action @transclude @model @sending @accepting>
    <data ... >
       <data ... />
    </data>
  </data>
  <error>
    <data @id @name @rel @label @url @templated @action @transclude @model @sending @accepting>
       <data ... />
    </data>
  </error>
</uber>

3.6. The <uber> Element

This is the root element of an UBER document. Every UBER document MUST have this as its root. The <uber> element has one optional property: version which carries the UBER document version information. For this release, all UBER documents SHOULD be set to the value of "1.0". If the version property is missing, it SHOULD be assumed to be set to "1.0".

Example <uber> Elements
<!-- XML format -->
<uber version="1.0">
...
</uber>

// JSON format
{"uber" : {"version" : "1.0", ...} }

3.7. The <data> Element

The <data> element is the key element in the model. A valid UBER document SHOULD contain at least one <data> element. If it does appear, the <data> element appears as a child of the <uber> or <error> elements. The <data> element MAY be nested as many times as needed. The <data> element has the following properties (all properties are OPTIONAL):

id

The document-wide unique identifier for this element. The value of id must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). If the id property is present, it SHOULD be treated as an in-document reference as described in section 3.5 of [RFC3986].

name

A document-wide non-unique identifier for this element. The value of name must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). If the name property is present it MAY be used as a variable in the UBER model property as described in [RFC6570].

rel

Contains a list of link relation values. These values SHOULD conform to the guidance provided in [RFC5988]. In the XML variant the list of link relation values appears as a space-separated list. In the JSON variant the list of link relation values appears as an array.

In UBER documents, the rel property is used to supply domain-related semantic information for the associated data element. This applies equally to data elements used as hypermedia links (e.g. those with a valid url property) and data elements used to carry simple values (e.g. strings and numbers).

label

Contains a string that represents the caption for the value property of the associated data element. The data element MAY contain this property. If it exists and contains a valid value, applications MAY use it when rendering the documents.

url

A resolvable URL associated with this element. If the templated property is set to true, the value of the url property SHOULD be treated as a URI Template per [RFC6570]. If the templated property is set of false, contains an unknown value, or is missing, the value of the url property SHOULD be treated as a URL per [RFC3986].

templated

If set to true the value of the url property SHOULD be treated as a URI Template per [RFC6570]. The default value is false.

action

The network request verb associated with this element. The list of valid values for this element are:

  • append : An unsafe, non-idempotent request to add a new item (e.g. HTTP.POST [RFC2616])

  • partial : An unsafe, non-idempotent request to modify parts of an existing item (e.g. HTTP.PATCH [RFC5789])

  • read : A safe, idempotent request (e.g. HTTP.GET [RFC2616])

  • remove : An unsafe, idempotent request to delete an existing item (e.g. HTTP.DELETE [RFC2616])

  • replace : An unsafe, idempotent request to replace an existing item (e.g. HTTP.PUT [RFC2616])

When the <data> element has a url property but no action property, it SHOULD be assumed the action property is set to read. Any unknown value MUST be treated as read.

transclude

Indicates whether the content that is returned from the URL should be embedded within the currently loaded document (transclude="true") or treated as a navigation to a new document (transclude="false"). If no transclude property exists, then the value of transclude SHOULD be assumed to be false (e.g. as a navigation). Any unsupported or unknown transclude value MUST be treated as a navigation.

model

Contains an [RFC6570]-compliant string to be used to construct message bodies. Variables in UBER model strings SHOULD be resolved using the values from name properties, but MAY come from any source available to the client application.

sending

Contains one or more media type identifiers for use when sending request bodies. One of the supplied identifiers SHOULD be selected as a guide when formatting the request body. For HTTP implementations, the selected identifier SHOULD be used as the value for the Content-Type header. If this property is missing the setting should be assumed to be application/x-www-form-urlencoded as described in [RFC1867].

In the XML variant the list of media-type identifiers appears as a space-separated list. In the JSON variant the list of media-type identifiers appears as an array.

accepting

Contains one or more media type identifiers to expect when receiving request bodies. The contents of this property SHOULD indicate the formats in which the server is able to return a response body. For HTTP implementations the contents of this property SHOULD be used as the value for the Accept header. If this property is missing, the setting should be assumed to be set to the same value as that of the currently loaded representation (application/vnd.uber+xml or application/vnd.uber+json).

In the XML variant the list of media-type identifiers appears as a space-separated list. In the JSON variant the list of media-type identifiers appears as an array.

value

In the XML variant of the UBER message format, inner text of the <data> element contains the value associated with that element.

In the JSON variant there is a value property that contains the associated value. Note that the content of this field MUST NOT be a JSON object or array and MUST be one of the following scalar values (listed in Section 2.1 of [RFC4627]):

  • number

  • string

  • false

  • true

  • null

For both the XML and JSON variants, it is the responsibility of the document author to make sure the contents of the value property are properly escaped as needed (per Section 2.4 of [REC-XML] and Section 2.5 of [RFC4627]).

Example <data> Elements (XML)
<uber version="1.0">
  <data rel="self" url="http://example.org/" />
  <data name="list" label="ToDo List" rel="collection" url="http://example.org/list/"/>
  <data name="search" label="Search" rel="search collection" url="http://example.org/search{?title}" templated="true" />
  <data name="todo" rel="item http://example.org/rels/todo" url="http://example.org/list/1">
    <data name="title" label="Title">Clean House</data>
    <data name="dueDate" label="Date Due">2014-05-01</data>
  </data>
  <data name="todo" rel="item http://example.org/rels/todo" url="http://example.org/list/2">
    <data name="title" label="Title">Paint the fence</data>
    <data name="dueDate" label="Date Due">2014-06-01</data>
  </data>
</uber>
Example <data> Elements (JSON)
{
  "uber" :
  {
    "version" : "1.0",
    "data" :
    [
      {
        "rel" : ["self"],
        "url" : "http://example.org/"
      },
      {
        "name" : "list",
        "label" : "ToDo List",
        "rel" : ["collection"],
        "url" : "http://example.org/list/"
      },
      {
        "name" : "search",
        "label" : "Search",
        "rel" : ["search","collection"],
        "url" : "http://example.org/search{?title}",
        "templated" : "true"
      },
      {
        "name" : "todo",
        "rel" : ["item","http://example.org/rels/todo"],
        "url" : "http://example.org/list/1",
        "data" :
        [
          {"name" : "title", "label" : "Title", "value" : "Clean house"},
          {"name" : "dueDate", "label" : "Date Due", "value" : "2014-05-01"}
        ]
      },
      {
        "name" : "todo",
        "rel" : ["item","http://example.org/rels/todo"],
        "url" : "http://example.org/list/2",
        "data" :
        [
          {"name" : "title", "label" : "Title", "value" : "Paint the fence"},
          {"name" : "dueDate", "label" : "Date Due", "value" : "2014-06-01"}
        ]
      }
    ]
  }
}

3.8. The <error> Element

The <error> element contains any error information returned by the server regarding the previous request. The <error> element has no properties. This is an OPTIONAL element. When present, it SHOULD contain one or more <data> child elements. It is the <data> child elements that contains error details.

Example <error> Element (XML)
<uber version="1.0">
  <error>
    <data name="type"
      rel="https://example.com/rels/http-problem#type">
      out-of-credit
    </data>
    <data name="title"
      rel="https://example.com/rels/http-problem#title">
      You do not have enough credit
    </data>
    <data name="detail"
      rel="https://example.com/rels/http-problem#detail">
      Your current balance is 30, but the cost is 50
    </data>
    <data name="balance"
      rel="https://example.com/rels/http-problem#balance">
      30
    </data>
  </error>
</uber>
Example <error> Element (JSON)
{
 "uber" :
 {
  "version" : "1.0",
  "error" :
  {
   "data" :
   [
    {
     "name" : "type",
     "rel" : ["https://example.com/rels/http-problem#type"],
     "value" : "out-of-credit"
    },
    {
     "name" : "title",
     "rel" : ["https://example.com/rels/http-problem#title"],
     "value" : "You do not have enough credit"
    },
    {
     "name" : "detail",
     "rel" : ["https://example.com/rels/http-problem#detail"],
     "value" : "Your balance is 30, but the cost is 50."
    },
    {
     "name" : "balance",
     "rel" : ["https://example.com/rels/http-problem#balance"],
     "value" : "30"
    }
   ]
  }
 }
}

4. Implementation Guidelines

Since the UBER message format was designed to work with multiple application protocols (HTTP, CoAP, etc.), there needs to be some guidelines for creating a protocol-specific implementation that supports UBER documents. Below is the HTTP guidance for UBER documents. This can be used as a guide in creating (and documenting) other protocol-specific implementations.

4.1. Supporting UBER Documents over HTTP

This section describes the details of implementing UBER support over HTTP.

4.1.1. Mapping UBER action Values to HTTP Methods

When implementing support for UBER documents over HTTP one of the key details is to map the value of UBER’s action property to HTTP methods. Table #1 below provides this mapping:

Table 1. Mapping HTTP Methods to UBER action Values
UBER Action HTTP Method

append

POST

partial

PATCH

read

GET

remove

DELETE

replace

PUT

4.1.2. Using UBER url Values to create HTTP Query Strings

If the templated property of a data element is set to true the url property SHOULD be treated as a URI Template per [RFC6570]. The following example shows how an UBER document snippet is converted into a valid HTTP query string:

Converting an UBER read Action into an HTTP Query String
<!-- Uber snippet -->
<data name="search"
  rel="search"
  templated="true"
  url="http://example.org/search{?givenName,familyName,email}"
  action="read"
/>

Assume the values supplied are:
  givenName = Mike
  familyName = Amundsen
  email = mike@example.org

*** HTTP Request ***
GET /search/?givenName=Mike&familyName=Amundsen&email=mike%40example.org HTTP/1.1
Host: example.org
Accept-Type: application/vnd.uber+xml

4.1.3. Using UBER model Values to create HTTP Request Bodies

Any model value associated with a data element SHOULD be converted into a valid HTTP request body using the rules contained in [RFC6570]. The following example shows how an UBER document snippet is converted into a valid HTTP request body:

Converting an UBER append Action into an HTTP Request
<!-- Uber snippet -->
<data name="create"
  rel="http://example.org/rels/create"
  url="http://example.org/people/"
  model="g={givenName}&f={familyName}&e={email}&a={avatarUrl}"
  action="append" />

Assume the values supplied are:
  givenName = Mike
  familyName = Amundsen
  email = mike@example.org
  avatarUrl = http://example.org/avatars/mike.png

*** HTTP Request ***
POST /people/ HTTP/1.1
Host: example.org
Accept-Type: application/vnd.uber+xml
Content-Type: application/x-www-form-urlencoded
Content-Length: xxx

g=Mike&f=Amundsen&e=mike%40example.org&a=http%3A%2F%2Fexample.org%2Favatars%2Fmike.png

4.2. Supporting UBER Documents Over other Protocols

It is possible that UBER documents can be exchanged using a protocol other than HTTP. In that case, it is the responsibility of the implementor to provide a guideline document that covers the same material included in the "Implementation Guidelines" of the UBER document specification.

5. Document Examples

UBER documents may appear in XML or JSON formats. Below are examples of each.

5.1. XML Example

Below is an XML Example of an UBER document.

XML Example
<uber version="1.0">
  <data rel="self" url="http://example.org/" />
  <data rel="profile" url="http://example.org/profiles/people-and-places/" />

  <data id="people" rel="collection http://example.org/rels/people" url="http://example.org/people/">
    <data name="create"
      rel="http://example.org/rels/create"
      url="http://example.org/people/"
      model="g={givenName}&f={familyName}&e={email}&a={avatarUrl}"
      action="append" />
    <data name="search"
      rel="search collection"
      url="http://example.org/search{?givenName,familyName,email}"
      templated="true" />

    <data name="person" rel="item http://example.org/rels/person" url="http://example.org/people/1">
      <data name="givenName" label="First Name">Mildred</data>
      <data name="familyName" label="Last Name">Amundsen</data>
      <data name="email" label="E-mail">mildred@example.org</data>
      <data name="avatarUrl" url="http://example.org/avatars/1"
        transclude="true" accepting="image/*">User Photo</data>
    </data>
    <data name="person" rel="item http://example.org/rels/person" url="http://example.org/people/2">
      <data name="givenName" label="First Name">Mildred</data>
      <data name="familyName" label="Last Name">Amundsen</data>
      <data name="email" label="E-mail">mildred@example.org</data>
      <data name="avatarUrl" url="http://example.org/avatars/2"
        transclude="true" accepting="image/*">User Photo</data>
    </data>
  </data>

  <data id="places" rel="collection http://example.org/rels/places" url="http://example.org/places/">
    <data name="search"
      rel="search collection"
      url="http://example.org/search{?addressRegion,addressLocality,postalCode}"
      templated="true" />

    <data name="place" url="http://example.org/places/1" rel="item http://example.org/rels/place">
      <data name="name">Home</data>
      <data name="address">
        <data name="streetAddress" label="Street Address">123 Main</data>
        <data name="addressLocality" label="City">Byteville</data>
        <data name="addressRegion" label="State">MD</data>
        <data name="postalCode" label="ZIP">12345</data>
      </data>
    </data>
    <data name="place" url="http://example.org/places/2" rel="item http://example.org/rels/place">
      <data name="name">Work</data>
      <data name="address">
        <data name="streetAddress" label="Street Address">456 Grand Ave.</data>
        <data name="addressLocality" label="City">Byteville</data>
        <data name="addressRegion" label="State">MD</data>
        <data name="postalCode" label="ZIP">12345</data>
      </data>
    </data>
  </data>

</uber>

5.2. JSON Example

Below is a JSON Example of an UBER document.

UBER JSON Example
{
  "uber" :
  {
    "version" : "1.0",
    "data" :
    [
      {"rel" : ["self"], "url" : "http://example.org/"},
      {"rel" : ["profile"], "url" : "http://example.org/profiles/people-and-places"},
      {
        "id" : "people",
        "rel" : ["collection","http://example.org/rels/people"],
        "url" : "http://example.org/people/",
        "data" :
        [
          {
            "name" : "create",
            "rel" : ["http://example.org/rels/create"],
            "url" : "http://example.org/people/",
            "model" : "g={givenName}&f={familyName}&e={email}",
            "action" : "append"
          },
          {
            "name" : "search",
            "rel" : ["search","collection"],
            "url" : "http://example.org/people/search{?givenName,familyName,email}",
            "templated" : "true"
          },
          {
            "name" : "person",
            "rel" : ["item","http://example.org/rels/person"],
            "url" : "http://example.org/people/1",
            "data" :
            [
              {"name" : "givenName", "value" : "Mike", "label" : "First Name"},
              {"name" : "familyName", "value" : "Amundsen", "label" : "Last Name"},
              {"name" : "email", "value" : "mike@example.org", "label" : "E-mail"},
              {"name" : "avatarUrl", "transclude" : "true",
                  "url" : "http://example.org/avatars/1",
                  "value" : "User Photo",
                  "accepting" : ["image/*"]
              }
            ]
          },
          {
            "name" : "person",
            "rel" : ["item","http://example.org/rels/person"],
            "url" : "http://example.org/people/2",
            "data" :
            [
              {"name" : "givenName", "value" : "Mildred", "label" : "First Name"},
              {"name" : "familyName", "value" : "Amundsen", "label" : "Last Name"},
              {"name" : "email", "value" : "mildred@example.org", "label" : "E-mail"},
              {"name" : "avatarUrl", "transclude" : "true",
                  "url" : "http://example.org/avatars/2",
                  "value" : "User Photo",
                  "accepting" : ["image/*"]
              }
            ]
          }
        ]
      },

      {
        "id" : "places",
        "rel" : ["collection","http://example.org/rels/places"],
        "url" : "http://example.org/places/",
        "data" :
        [
          {
            "name" : "search",
            "rel" : ["search","collection"],
            "url" : "http://example.org/places/search{?addressRegion,addressLocality,postalCode}",
            "templated" : "true"
          },
          {
            "name" : "place",
            "rel" : ["item","http://example.org/rels/place"],
            "url" : "http://example.org/places/a",
            "data" :
            [
              {
                "name" : "name",
                "value" : "Home"
              },
              {
                "name" : "address",
                "data" :
                [
                  {"name" : "streetAddress", "value" : "123 Main Street", "label" : "Street Address"},
                  {"name" : "addressLocalitly", "value" : "Byteville", "label" : "City"},
                  {"name" : "addressRegion", "value" : "MD", "label" : "State"},
                  {"name" : "postalCode", "value" : "12345", "label" : "ZIP"}
                ]
              }
            ]
          },
          {
            "name" : "place",
            "rel" : ["item","http://example.org/rels/place"],
            "url" : "http://example.org/places/b",
            "data" :
            [
              {
                "name" : "name",
                "value" : "Work"
              },
              {
                "name" : "address",
                "data" :
                [
                  {"name" : "streetAddress", "value" : "1456 Grand Ave.", "label" : "Street Address"},
                  {"name" : "addressLocalitly", "value" : "Byteville", "label" : "City"},
                  {"name" : "addressRegion", "value" : "MD", "label" : "State"},
                  {"name" : "postalCode", "value" : "12345", "label" : "ZIP"}
                ]
              }
            ]
          }
        ]
      }
    ]
  }
}

6. Supporting Profiles

The UBER media-type supports the use of semantic profiles via the ‘profile’ link relation type [RFC6906] in order to provide additional information about the application-level semantics for the document body. The profile value is a list of one or more IRIs identifying specific constraints or conventions that apply to an UBER document.

The profile value MUST NOT change the semantics of the resource representation when processed without the profile value. The profile value MAY also be used by clients to express their preferences. Profile IRIs SHOULD be dereferenceable and SHOULD provide additional related semantic information.

Use of profiles is OPTIONAL. Servers MAY ignore this value when sent by the client. Clients MAY ignore this value when sent by the server.

This version of the UBER specification supports three ways to communicate profile information:

  1. The profile parameter in the media type identifier

  2. A LINK header with rel="profile"

  3. Within the UBER document body as a data element with a rel property value of "profile".

Depending on the protocol in use, one or more of these methods MAY be used in the same request. For example, in an HTTP exchange a sender MAY use an Accept or Content-Type header that contains a profile value and a Link header that contains a profile value and a document body that contains a profile value. When this occurs, the recipient SHOULD honor all the profile values received.

6.1. Profile Media-Type Parameter

Profile information can be supplied via the media type profile parameter. Examples of valid profile media-type parameters in HTTP messages are:

 Accept: application/vnd.uber+json;profile=http://example.org/profiles/vcard
 Content-Type: application/vnd.uber+xml;profile=http://example.org/profiles/vcard http://schema.org/Person

6.2. Profile Link Header

The Link Header [RFC5988] can also be used to communicate profile details. Examples of valid profile Link headers are:

 Link: <http://example.org/profiles/vcard>; rel="profile"
 Link: <http://example.org/profiles/vcard>; rel="profile", <http://schema.org/Person>; rel="profile"

6.3. Profile Link Element

Profile information can be supplied as one or more data elements within an UBER document body. Examples of valid profile elements within an UBER document are:

  <data rel="profile" url="http://example.org/profiles/people-and-places/" />
  {"data" : [{"rel" : ["profile"], "url" : "http://example.org/profiles/people-and-places"}]}

7. Extensibility

This specification describes the UBER document-format’s markup vocabulary. Markup from other vocabularies ("foreign markup") can be used in an UBER document. Any extensions to the UBER Hypermedia vocabulary MUST NOT redefine any objects (or their properties), arrays, properties, link relations, or data types defined in this document. Clients that do not recognize extensions to the UBER vocabulary SHOULD ignore them.

The details of designing and implementing UBER extensions is beyond the scope of this document.

Note

It is possible that future forward-compatible modifications to this specification will include new objects, arrays, properties, link-relations, and data types. Extension designers should take care to prevent future modifications from breaking or redefining those extensions.

8. IANA Considerations

Below are the related IANA considerations for this media type design.

8.1. XML Media Type Registration

[pending submission]

8.2. JSON Media Type Registration

[pending submission]

8.3. Security Considerations

The XML variant of the UBER document format shares security issues common to all XML content types. It does not provide executable content. Information contained in UBER documents do not require privacy or integrity services.

The JSON variant of the UBER document format shares security issues common to all JSON content types. See RFC4627 Section #6 [RFC4627] for additional information. The UBER document format does not provide executable content. Information contained in UBER documents do not require privacy or integrity services.

8.4. Internationalization Considerations

The UBER document format does not have any internationalization considerations other than those which are discussed in referenced RFC documents (see below).

9. References

Below are the references used in this document.

9.1. Normative References

9.2. Informative References

10. Acknowledgements

The authors would like to thank everyone who commented upon, encouraged, and gave feedback to this specification, especially Cédric Brancourt, Mark W. Foster, Ben Hamill, Steve Klabnik, Matthew McClure, Stephen Mizell, Thomas Eizinger, Erik Wilde.

.