Cloud Data Management Interface (CDMI) Media Types
draft-cdmi-mediatypes-01

Abstract

This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are:

• application/cdmi-domain
• application/cdmi-capability
• application/cdmi-container
• application/cdmi-object and
• application/cdmi-queue

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on March 31, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Cloud Data Management Domain and its Relevance
3.  Processing Guidelines
    3.1.  Type : application/cdmi-object
    3.2.  Type : application/cdmi-container
    3.3.  Type : application/cdmi-domain
    3.4.  Type : application/cdmi-capability
    3.5.  Type : application/cdmi-queue
4.  Transport Considerations
5.  Acknowledgements
6.  IANA Considerations
    6.1.  Media Type application/cdmi-capability
    6.2.  Media Type application/cdmi-container
    6.3.  Media Type application/cdmi-domain
    6.4.  Media Type application/cdmi-object
    6.5.  Media Type application/cdmi-queue
7.  Security Considerations
    7.1.  Confidentiality and Integrity
    7.2.  Access Control
    7.3.  Audit
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

The Cloud Data Management Interface (CDMI) [CDMI‑1] (SNIA, “Cloud data management Interface Version 1.0,” 2010.) developed by the Storage Networking Industry Association (SNIA) is the functional interface that applications will use to create, retrieve, update and delete data elements from the cloud. As part of this interface the client will be able to discover the capabilities of the cloud storage offering and use this interface to manage containers and the data that is placed in them. In addition, metadata can be set on containers and their contained data elements through this interface.

1.1.  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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Cloud Data Management Domain and its Relevance

A storage cloud is a storage service hosted either on-premise or off-premise, definitely across a network. An important part of the cloud model, in general, is the concept of a pool of resources that is drawn from, on demand, in small increments (smaller than what one would typically purchase by buying equipment). By abstracting data storage behind a set of service interfaces and delivering it on demand, a wide range of actual offerings and implementations are possible. The only type of storage that is excluded from this definition is that which is delivered, not based on demand, but on fixed capacity increments.

The CDMI defines a set of functional interfaces (data paths) and management interfaces (control paths) to create, retrieve, update, and delete data elements from a storage cloud. Another important concept in this standard is that of metadata. When managing large amounts of data with differing requirements, metadata is a convenient mechanism to express those requirements in such a way that underlying data services can differentiate their treatment of the data to meet those requirements. CDMI also defines an extensible metadata system for storage clouds.

As part of the CDMI interface, the client will be able to discover the capabilities of the cloud storage offering and to use this interface to manage containers and the data that is placed in them. In addition, data system metadata can be set on containers and their contained data elements through this interface.

The hierarchy that CDMI defines is as follows:

• The basic element of storage is an object
• Objects are stored in a container hierarchy
• CDMI also defines an object, called a queue, which has special properties for in-order, first in, first-out creation and fetching of queue objects, similar to a container of data objects.
• A cloud offering can also support domains, which allow administrative ownership to be associated with stored objects. Domains can also be hierarchical, allowing for corporate domains with multiple children domains for departments or individuals. The domain concept is also used to map ACLs to principals as well as to aggregate usage data that is used to bill, meter, and monitor cloud usage. (Note: The CDMI "domain" defined here is not a DNS domain name as specified in RFCs 1023 and 1024.)
• Finally, a capabilities resource and associated URI allows a client to discover the capabilities of the offering and its implementation of CDMI.

3.  Processing Guidelines

In this section we summarize the processing of each media type. In this document we provide only the essential information. The CDMI specification [CDMI‑1] (SNIA, “Cloud data management Interface Version 1.0,” 2010.) which has more details and appropriate examples, is the final authority on the processing aspects.

3.1.  Type : application/cdmi-object

A CDMI object is the basic storage element in a CDMI system and are analogous to files within a filesystem. The object is represented in the CDMI interface in JSON [JSON‑1] (json.org, “JavaScript Object Notation,” 2006.) format. RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627] defines the JSON format. Each data object has a set of well-defined fields that include a single value and optional metadata. The implementations are free to store the data in any form they choose, but the application/cdmi-object should be represented in the CDMI interface as defined in section 8 of the CDMI specification.

3.2.  Type : application/cdmi-container

Container objects are the fundamental grouping of stored data within CDMI and is analogous to directories within a filesystem. Each container has zero or more child objects and a set of well-defined fields that include standardized and optional metadata. The implementations are free to represent the container in amy form they choose, but the application/cdmi-container should be represented in the CDMI interface as defined in section 9 of the CDMI specification.

3.3.  Type : application/cdmi-domain

Domain objects represent the concept of administrative ownership of stored data within a CDMI storage system. A CDMI offering may include a hierarchy of domains that provide access to domain-related information within a CDMI context. This domain hierarchy is a series of CDMI objects that correspond to parent and child domains, with each domain corresponding to logical groupings of objects that are to be managed together. Section 10 of the CDMI specification details the information content, representation and processing on domain objects

3.4.  Type : application/cdmi-capability

Capability objects are a special class of container object that allow a CDMI client to discover what subset of the CDMI standard is implemented by a CDMI provider. For each URI in a CDMI system, the set of interactions that the system is capable of performing against that URI are described by the presence of named "capabilities". Each capability present for a given URI indicates what functionality the cloud storage system will allow against that URI. Capabilities are always static. Section 12 of the CDMI specification details the representation and processing of capability objects

3.5.  Type : application/cdmi-queue

Queues are a special class of container object and are used to provide first-in, first-out access when storing and retrieving data. A queue writer PUTs objects to the queue, and a queue reader GETs objects from the queue, acknowledging the receipt of the last object that it received. Queuing provides a simple mechanism for one or more writers to send data to a single reader in a reliable way. If supported by the cloud storage system, cloud clients create the queue objects by using the same mechanism used to create data objects. Section 11 of the CDMI specification details the operations and processing of queue objects

4.  Transport Considerations

The CDMI uses HTTP (RFC 2616) transport and does not make sense outside the HTTP realm. We do not expect the CDMI to use other transports like SMTP (RFC2821) or raw TCP (RFC 793) protocols.

5.  Acknowledgements

The authors wish to acknowledge the guidance and wisdom from Mark Carlson, Peter Saint-Andre, comments from Patrick Faltstrom and the SNIA CDMI cloud twg for all the insightful discussions and ideas.

6.  IANA Considerations

This memo includes a request to IANA to register the following media types :

• application/cdmi-domain
• application/cdmi-capability
• application/cdmi-container
• application/cdmi-object and
• application/cdmi-queue

6.1.  Media Type application/cdmi-capability

Type name: application

Subtype name: cdmi-capability

Required parameters: none

Optional parameters: none

Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). The primary transport is HTTP and a base64 encoding is appropriate when transporting such objects over other transports like email.

Security considerations: See Section 7 of draft-cdmi-mediatypes-01

Interoperability considerations: none

Published specification: draft-cdmi-mediatypes-01

Applications that use this media type: Implementations of the Cloud Data Management Interface (CDMI) defined by the Storage Networking Industry Association (SNIA)

Additional information:

Magic number(s): none

File extension(s): none

Macintosh file type code(s): none

Person and email address to contact for further information: Arnold Jones arnold.jones@snia.org

Intended usage: COMMON

Restrictions on usage: none

Author: SNIA Cloud Storage Initiative cloudtwg@snia.org

Change controller: SNIA Cloud Storage Initiative cloudtwg@snia.org

6.2.  Media Type application/cdmi-container

Type name: application

Subtype name: cdmi-container

Required parameters: none

Optional parameters: none

Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). The primary transport is HTTP and a base64 encoding is appropriate when transporting such objects over other transports like email.

Security considerations: See Section 7 of draft-cdmi-mediatypes-01

Interoperability considerations: none

Published specification: draft-cdmi-mediatypes-01

Applications that use this media type: Implementations of the Cloud Data Management Interface (CDMI) defined by the Storage Networking Industry Association (SNIA)

Additional information:

Magic number(s): none

File extension(s): none

Macintosh file type code(s): none

Person and email address to contact for further information: Arnold Jones arnold.jones@snia.org

Intended usage: COMMON

Restrictions on usage: none

Author: SNIA Cloud Storage Initiative cloudtwg@snia.org

Change controller: SNIA Cloud Storage Initiative cloudtwg@snia.org

6.3.  Media Type application/cdmi-domain

Type name: application

Subtype name: cdmi-domain

Required parameters: none

Optional parameters: none

Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). The primary transport is HTTP and a base64 encoding is appropriate when transporting such objects over other transports like email.

Security considerations: See Section 7 of draft-cdmi-mediatypes-01

Interoperability considerations: none

Published specification: draft-cdmi-mediatypes-01

Applications that use this media type: Implementations of the Cloud Data Management Interface (CDMI) defined by the Storage Networking Industry Association (SNIA)

Additional information:

Magic number(s): none

File extension(s): none

Macintosh file type code(s): none

Person and email address to contact for further information: Arnold Jones arnold.jones@snia.org

Intended usage: COMMON

Restrictions on usage: none

Author: SNIA Cloud Storage Initiative cloudtwg@snia.org

Change controller: SNIA Cloud Storage Initiative cloudtwg@snia.org

6.4.  Media Type application/cdmi-object

Type name: application

Subtype name: cdmi-object

Required parameters: none

Optional parameters: none

Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). The primary transport is HTTP and a base64 encoding is appropriate when transporting such objects over other transports like email.

Security considerations: See Section 7 of draft-cdmi-mediatypes-01

Interoperability considerations: none

Published specification: draft-cdmi-mediatypes-01

Applications that use this media type: Implementations of the Cloud Data Management Interface (CDMI) defined by the Storage Networking Industry Association (SNIA)

Additional information:

Magic number(s): none

File extension(s): none

Macintosh file type code(s): none

Person and email address to contact for further information: Arnold Jones arnold.jones@snia.org

Intended usage: COMMON

Restrictions on usage: none

Author: SNIA Cloud Storage Initiative cloudtwg@snia.org

Change controller: SNIA Cloud Storage Initiative cloudtwg@snia.org

6.5.  Media Type application/cdmi-queue

Type name: application

Subtype name: cdmi-queue

Required parameters: none

Optional parameters: none

Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). The primary transport is HTTP and a base64 encoding is appropriate when transporting such objects over other transports like email.

Security considerations: See Section 7 of draft-cdmi-mediatypes-01

Interoperability considerations: none

Published specification: draft-cdmi-mediatypes-01

Applications that use this media type: Implementations of the Cloud Data Management Interface (CDMI) defined by the Storage Networking Industry Association (SNIA)

Additional information:

Magic number(s): none

File extension(s): none

Macintosh file type code(s): none

Person and email address to contact for further information: Arnold Jones arnold.jones@snia.org

Intended usage: COMMON

Restrictions on usage: none

Author: SNIA Cloud Storage Initiative cloudtwg@snia.org

Change controller: SNIA Cloud Storage Initiative cloudtwg@snia.org

7.  Security Considerations

This section was developed with RFC 3552 (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) [RFC3552] as guide. CDMI is an application interface and the relevant security considerations include confidentiality, integrity, access control and audit. Transport and end point security artifacts like DDoS are orthogonal and domains like non-repudiation are left to the application that employs this interface

7.1.  Confidentiality and Integrity

The Confidentiality and integrity of the CDMI exchanges are determined by the application that uses the interface.CDMI does not contain any specific mechanisms and relies on transport mechanisms like https [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) for confidentiality and integrity of the messages across the network

7.2.  Access Control

The access control of the CDMI end point URLs are beyond this specification. If required applications should use appropriate URL authentication and authorization techniques.

For fine grained control of the CDMI objects, the CDMI specification contains the Access Control Lists (ACL) and Access Control Entries (ACE). These are described fully i section 16.1 of the CDMI specification

7.3.  Audit

The CDMI specification has a set of metadata fields as explained in Section 16.3 to facilitate the access and other audit markers. The CDMI metadata system is extensible and the implementations can add more metadata as required by the security posture of the domain.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses