An HTTP-based Decade Resource Protocol
draft-wang-decade-drp-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Wang Danhua , Hongqiang Liu , Y. Richard Yang | ||
| Last updated | 2012-03-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-decade-drp-03
Network Working Group D. Wang
Internet-Draft Huawei Technologies
Intended status: Standards Track H. Liu
Expires: September 13, 2012 Y. Yang
Yale University
Mar 12, 2012
An HTTP-based Decade Resource Protocol
draft-wang-decade-drp-03
Abstract
This document explorers the design of an HTTP-based DECADE Resource
Protocol (DRP), which can be used for content and resource management
between a DECADE Client and a DECADE Server, or between two DECADE
Servers. We identify the function entities, and present initial
protocol message flow and syntax design. The purpose of this
document is to get design discussion started, not to provide a
complete solution.
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 September 13, 2012.
Copyright Notice
Copyright (c) 2012 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
Wang, et al. Expires September 13, 2012 [Page 1]
Internet-Draft DRP Mar 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Function Entities . . . . . . . . . . . . . . . . . . . . 4
3.3. Protocol Architecture . . . . . . . . . . . . . . . . . . 4
3.4. Object Naming . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Protocol Operations . . . . . . . . . . . . . . . . . . . 4
4. Access and Resource Control . . . . . . . . . . . . . . . . . 5
5. Token Structure/HTTP Authentication Format . . . . . . . . . . 6
6. Message Syntax and Processing . . . . . . . . . . . . . . . . 7
6.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Common Message Processing . . . . . . . . . . . . . . . . 7
6.3. DECADE Messages . . . . . . . . . . . . . . . . . . . . . 8
6.3.1. Transport_Query Message . . . . . . . . . . . . . . . 8
6.3.2. Access_Token Message . . . . . . . . . . . . . . . . . 9
6.3.3. Server_States_Query Message . . . . . . . . . . . . . 10
6.3.4. Object_Property_Query Message . . . . . . . . . . . . 12
6.3.5. Object_Property_Set Message . . . . . . . . . . . . . 14
6.3.6. Delete_Data Message . . . . . . . . . . . . . . . . . 15
6.4. Error Response Messages . . . . . . . . . . . . . . . . . 16
7. Integration with an HTTP-based SDT . . . . . . . . . . . . . . 17
7.1. Put_Object Message . . . . . . . . . . . . . . . . . . . . 17
7.2. Get_Object Message . . . . . . . . . . . . . . . . . . . . 18
8. Remote_Get_Object Message . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative Reference . . . . . . . . . . . . . . . . . . . 20
12.2. Informative Reference . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Wang, et al. Expires September 13, 2012 [Page 2]
Internet-Draft DRP Mar 2012
1. Introduction
The DECADE Architecture document [I-D.ietf-decade-arch-03] identifies
a DECADE architecture that consists of two logically independent
protocols: the DECADE Resource Protocol (DRP) and the Standard Data
Transport (SDT). The former provides access control and resource
scheduling between two DECADE peers, while the latter is used to
transfer data objects to and from a DECADE Server. The architecture
document observes that the two protocols may be realized on the same
wire.
In this document, we present an initial design of a DRP based on
HTTP. We use the DECADE requirements [I-D.ietf-decade-reqs-04] to
guide our design. The purpose of this document is to get design
discussions started, not to provide a complete solution.
Specifically, the DRP we present provides a signaling layer for
transport negotiation, content management, access control and
resource control. The SDT is responsible for data put, retrieve,
delete, and metadata update, and the implementation of access control
and resource control policies.
We also show that the HTTP based DRP may be extended to include an
HTTP based SDT, achieving a same-wire design, although it is also
possible to use another SDT.
2. Terminologies and concepts
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", "MAY NOT" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This draft uses the terms defined in [I-D.ietf-decade-reqs-04] and in
[I-D.ietf-decade-arch-03].
DECADE peers: Entities involved in the DRP, such as a DECADE Server
or a DECADE Client.
3. Protocol Overview
3.1. Overview
The DECADE Protocol is spoken between a DECADE Client and a DECADE
Server or between two DECADE Servers to manage, store, and retrieve
data objects for data distribution. A DECADE Client can be an
application server, or embedded in a web browser, etc.
Wang, et al. Expires September 13, 2012 [Page 3]
Internet-Draft DRP Mar 2012
We use the scheme where DECADE uses a data-derived naming scheme to
achieve content security and de-duplication. In this initial design,
we assume that the name space is flat for simplicity. We anticipate
that the naming scheme may allow for group operations on a set of
data objects with a similar/same attribute.
3.2. Function Entities
We consider two primary function entities involved in DECADE: the
DECADE Server and the DECADE Client.
DECADE Server: A DECADE Server stores DECADE data inside the network,
and thereafter manages both the stored data and access to that data
[I-D.ietf-decade-arch-02].
DECADE Client: A DECADE Client stores and retrieves data at DECADE
Servers [I-D.ietf-decade-arch-02].
3.3. Protocol Architecture
+------+ DRP +------+
|DECADE|<--------------->|DECADE|
|Server|<--------------->|Server|
+------+ SDT +------+
^ ^ ^ ^
| | | |
DRP| | SDT DRP| |SDT
| | | |
v v v v
+------+ +------+
|DECADE| |DECADE|
|Client| |Client|
+------+ +------+
3.4. Object Naming
(To be added...)
3.5. Protocol Operations
The DRP we present is a request-response protocol. Requests and
corresponding responses are exchanged between a DECADE Client and a
DECADE Server or between two DECADE Servers. A request includes an
Access Token, which allows the DECADE Server to limit access and
implement resource control. In particular, a token specifies
permitted operations to permitted objects by permitted clients during
permitted period, as well as priority for bandwidth given to
requested operation, and so on.
Wang, et al. Expires September 13, 2012 [Page 4]
Internet-Draft DRP Mar 2012
In particular, we identify the following management requests:
Query Server Status (from the system's view): This operation
allows a DECADE Client to query statue information of a specific
DECADE Server from the server view, e.g., lists of associated
objects, resource used/available, and so on.
Query Server Status (from the user's view): This operation allows
a DECADE Client to query status specific to itself, e.g., list of
associated objects that the DECADE Client stored in the Server,
the Client's available resources, and so on.
Query Object Property: This operation allows a DECADE Client to
query object properties, including TTL of objects, object sizes.
Set Object Property: This operation allows a DECADE Client to set
data object properties.
Delete Data Object: This operation is used to delete data objects
from a DECADE Server.
Complementing the preceding DRP operations, we define the following
SDT operations archieve a complete DECADE Protocol:
Put Data Object: This operation is used to write data objects to a
DECADE Server.
Get Data Object: This operation is used to download data objects
from a DECADE Server.
4. Access and Resource Control
We start with a brief evaluation on the feasibility of using an
existing IETF protocol for resource control in DECADE. In
particular, we evaluate the feasibility of extending an existing
protocol for granting a third party access to the resource and data
objects owned by a resource/data owner. We consider the
applicability of OAuth, AAA, and Kerberos.
In Kerberos [RFC4120], a client obtains Tickets to obtain services.
Specifically, in Kerberos, a client first obtains a Client/TGS
session key and a Ticket-Granting-Ticket from an authentication
server. An issue of this approach, however, is that it requires a
client to authenticate with the system. Hence, it may work well in a
single DECADE domain system where each client has an account at a
DECADE provider. On the other hand, DECADE should also work in an
inter-domain setting, where a client may not have an account on a
Wang, et al. Expires September 13, 2012 [Page 5]
Internet-Draft DRP Mar 2012
DECADE server. Hence, extensions could be challenging.
Radius [RFC 2865] [RFC 2866] and its successor Diameter [RFC 3588]
are the base AAA protocols. Although extending the binary attribute-
value-pairs (AVPs) may be possible to grant network resources for
data access, the resource control communication points in the DECADE
environment are application clients/servers and DECADE servers, and
hence a text-based protocol may be preferred by the application
clients. However, this should not prevent that the Diameter protocol
be used between a DECADE server and an application server for AAA
purposes.
OAuth v2 [draft-ietf-oauth-protocol-v2-23] is used to grant access to
the resource owner's resources from a third party without explicitly
exposing the resource owner's credentials. It currently focuses on
the context of HTTP [RFC2616]. The three-leg-style access assumption
is different from the access requirement in the DECADE system
environment. Howerver, some grant types may be adopted (such as
implicit grant) and extensions can be added for resource control.
5. Token Structure/HTTP Authentication Format
A primary use case for DECADE is that a DECADE Client authorizes
other DECADE Clients to store or retrieve data objects from its
DECADE storage. Therefore, we explore a DECADE protocol using a
token-based authorization scheme instead of explicitly manipulating
an Access Control List (ACL) for each DECADE data object.
Tokens can be generated by a DECADE Client itself or any of its
trusted parties/entities. After a token has been generated, it can
be distributed to other DECADE Clients for them to request for access
to the DECADE Server. In this way, token can support anonymous
access, and a DECADE Server does not need to know the identity of
each DECADE Client that accesses it.
In order to provide a complete authorization scheme, the token MUST
carry the following information: Permitted operations, Permitted
objects, Permitted Clients, Expiration time, Priority for bandwidth
given to requested operation, and Amount of data that may be read or
written.
The token can be carried with the request message. A possibility of
a header for signature is:
X-DECADE-TOKEN: DECADE keyID;signature
The "signature" represents alphanumeric or numeric data to be
Wang, et al. Expires September 13, 2012 [Page 6]
Internet-Draft DRP Mar 2012
inserted, which includes necessary authentication information
described before. A design is that the siganture is calculated based
on HMAC-SHA1.
signature = Base64(HMAC-SHA1(UTF-8-Encoding-Of(StringToSign)))
StringToSign = PermittedOperation1 + "\n" + ... + PermittedOperationm
+ "\n" + PermittedObject1 + "\n" + ... + PermittedObjectn + "\n" +
TTL + "\n" + Priority for bandwidth given to requested operation +
"\n" + Amount of data that may be read or written + "\n"key
After the DECADE Server receives a request, it verifies the
authorization by checking the token. If the token is valid, the
request/certain operations will be authenticated, otherwise, it will
be rejected. If the token is successfully validated, the DECADE
Server applies the resources control policies indicated in the token
while performing the operation.
6. Message Syntax and Processing
We now present the encoding and processing.
6.1. Encoding
The DRP in this document follows the standard request and response
formats for HTTP Request and Response messages [RFC2616].
Specifically, the header fields in both request and response messages
follows the standard rules for HTTP/1.1 Header fields, which MAY be
included in the messages if necessary.
We use JSON to encode the bodies for both request and response
messages.
In the following messages, both *** and XXX represent data to be
insert, either numeric data or alphanumeric data.
6.2. Common Message Processing
After receiving a DECADE protocol message, a DECADE server performs
some basic processing, regardless of the message type and the
receiving entity.
Specifically, upon receiving a message, the DECADE server ensures
that the message is properly formed. If not, appropriate standard
HTTP errors MUST be generated. Below are some examples.
Wang, et al. Expires September 13, 2012 [Page 7]
Internet-Draft DRP Mar 2012
If the message is found to be incorrectly formed or the length does
not match the length encoded in the header, the receiver MUST reply
with an HTTP 400 response.
If the version number is not supported by the receiver, the receiver
MUST reply with an HTTP 400 response.
If the receiver is unable to process the message temporarily because
it is in an overloaded state, the receiver SHOULD reply with an HTTP
503 response.
If the receiver encounters an internal error while attempting to
process the message, the receiver MUST generate an HTTP 500 response.
6.3. DECADE Messages
DECADE protocol can be divided into two layers, the signaling layer
and the transport layer. The signaling layer is responsible for
transport negotiation, data management, access control and resource
control. The Transport layer is responsible for data put, retrieve,
delete, metadata update, and the implementation of access control and
resource control policies. Therefore, SDT messages must be extended
to include tokens.
6.3.1. Transport_Query Message
A Transport_Query message is used to query a DECADE server about its
supported transports. A DECADE client will send a request to the
DECADE server to ask for the transport protocols supported by the
server. And then the DECADE server will send back a reply with the
supported transport protocols. A DECADE server must listen on the
server ports of the supported protocols (e.g. NFS). By that, the
DECADE client (active) can impose data operations on the DECADE
server using either one of the supported transport protocols
supported by the DECADE server. Below is an example Transport_Query
message:
GET /decade/transport/ HTTP/1.1
Host: example.com
Content-Length: ***
Content-Type: application/decade-transport-req+json
X-DECADE-Protocol-Version: 1.0
If the query message is valid, the DECADE Server sends back a
response listing the supported SDT protocols. An example is shown
below:
Wang, et al. Expires September 13, 2012 [Page 8]
Internet-Draft DRP Mar 2012
HTTP/1.1 200 OK
Content-Length: ***
Content-Type: application/decade-transport-ans+json
X-DECADE-Protocol-Version: 1.0
{
"transport-protocol":
{
"HTTP": true;
"NFS": true;
"WebDAV": true;
}
}
JSON Object:
Object {
JSONBool HTTP; [OPTIONAL]
JSONBool NFS; [OPTIONAL]
JSONBool WebDav; [OPTIONAL]
} TransportProtocol;
Object {
TransportProtocol transport-protocol;
}
When the DECADE Client receives the response from the Server, it will
choose a protocol that it supports and communicates with the Server
via the chosen protocol.
6.3.2. Access_Token Message
It is possible for a client to ask a DECADE server to generate a key,
instead of generating locally. An example message is as following:
POST /decade/token HTTP/1.1
Host: example.com
Content-Length: ***
Content-Type: application/decade-access-token-req+json
X-DECADE-Protocol-Version: 1.0
{
JSONString: DECADEClientId;
token parameters
}
If the DECADE Client identifier is valid and the request message is
successfully proceeded, the DECADE Server will reply with the
authenticate token. An example of the response message is as below:
Wang, et al. Expires September 13, 2012 [Page 9]
Internet-Draft DRP Mar 2012
HTTP/1.1 200 OK
Content-Type: application/decade-access-token-ans+json
X-DECADE-Protocol-Version: 1.0
{
JSONString: token;
}
6.3.3. Server_States_Query Message
This operation allows state query. The state can be either system-
wide or on a particular user. An example message is:
POST /decade/state HTTP/1.1
Host: example.com
Content-Length: ***
Content-Type: application/decade-stat-req+json
X-DECADE-Protocol-Version: 1.0
X-DECADE-TOKEN: DECADE signature
{
"state-request":
{
"StorageUsed": true;
"StorageAvailable": true;
"BandwidthUsed": true;
"BandwidthAvailable": true;
"ObjectNum": true;
"ObjectList": true;
}
"user-type":
{
"System": true;
}
"token":XXX;
}
JSON Object:
Object{
JSONBool StorageUsed; [OPTIONAL]
JSONBool StorageAvailable; [OPTIONAL]
JSONBool BandwidthUsed; [OPTIONAL]
JSONBool BandwidthAvailable; [OPTIONAL]
JSONBool ObjectNum; [OPTIONAL]
JSONBool ObjectList; [OPTIONAL]
}ServerState;
Wang, et al. Expires September 13, 2012 [Page 10]
Internet-Draft DRP Mar 2012
Object{
JSONBool System; [OPTIONAL]
JSONBool User; [OPTIONAL]
}UserType;
Object{
ObjectOperation permitted-operations<0..*>;
JSONObject permitted-objects;
JSONObject permitted-clients;
JSONNumber expiration-time;
JSONNumber priority;
}AuthToken;
Object{
ServerState server-state;
}
Object{
UserType user-type;
}
Object{
AuthToken token;
}
If a state query message is valid, the DECADE Server responses with
corresponding server state. If the "user-type" in the message body
is "System", then the server should return the status of resource
consumption on this server after verifying the user's access right.
Usually the right will be authorized to the system administrator. If
the "user-type" in the message body is "User", then the server should
return the status of resource consumption of this particular user on
this server after verifying the user's access right. An example of
the Response is as following:
Wang, et al. Expires September 13, 2012 [Page 11]
Internet-Draft DRP Mar 2012
HTTP/1.1 200 OK
Content-Length: ***
Content-Type: application/decade-stat-ans+json
X-DECADE-Protocol-Version: 1.0
{
"server-state":
{
"storage-used": ***;
"storage-available": ***;
"bandwidth-used": ***;
"bandwidth-available": ***;
"object-number": ***;
"object-list":
[
"data-object":
{
"object-name":XXX;
}
]
}
}
JSON Object:
Object{
JSONNumber storage-used; [OPTIONAL]
JSONNumber storage-available; [OPTIONAL]
JSONNumber bandwidth-used; [OPTIONAL]
JSONNumber object-number; [OPTIONAL]
JSONArray object-list["DataObject"]; [OPTIONAL]
}ServerState;
Object{
JSONString object-name;
}DataObject;
Object{
DataObject data-object;
}
6.3.4. Object_Property_Query Message
This operation allows a DECADE Client to query object properties with
certain authentication, including TTL of object, object size, and
object type. The request message is as following:
Wang, et al. Expires September 13, 2012 [Page 12]
Internet-Draft DRP Mar 2012
POST /decade/object/<obj-name>/property HTTP/1.1
Host: example.com
Content-Length: ***
Content-Type: application/decade-objprop-query-req+json
X-DECADE-Protocol-Version: 1.0
X-DECADE-TOKEN: DECADE signature
{
"token": XXX;
}
JSON Object:
Object{
ObjectOperation permitted-operations<0..*>;
JSONObject permitted-objects;
JSONObject permitted-clients;
JSONNumber expiration-time;
JSONNumber priority;
}AuthToken;
Object{
AuthToken token;
}
If the object property query message is valid and successfully
proceeded, the DECADE Server replies the request info. An example of
the response message is as below:
Wang, et al. Expires September 13, 2012 [Page 13]
Internet-Draft DRP Mar 2012
HTTP/1.1 200 OK
Content-Length: ***
Content-Type: application/decade-objprop-query-ans+json
X-DECADE-Protocol-Version: 1.0
{
"object-property":
{
"object-type": XXX;
"object-size": ***;
"owner": XXX;
"TTL": ***;
}
}
JSON Object:
Object{
JSONString object-type; [OPTIONAL]
JSONNumber object-size; [OPTIONAL]
JSONString owner; [OPTIONAL]
JSONNumber TTL; [OPTIONAL]
}ObjectProperty;
Object{
ObjectProperty object-property;
}
6.3.5. Object_Property_Set Message
This operation allows a DECADE Client to set object properties
(metadata). The request message is as following:
Wang, et al. Expires September 13, 2012 [Page 14]
Internet-Draft DRP Mar 2012
PUT /decade/<obj-name>/property HTTP/1.1
Host: example.com
Content-Length: ***
Content-Type: application/decade-objprop-set-req+json
X-DECADE-Protocol-Version: 1.0
X-DECADE-TOKEN: DECADE signature
{
"object-property":
{
"TTL": ***;
}
"token": XXX;
}
JSON Object:
Object{
JSONNumber TTL; [OPTIONAL]
}ObjectProperty;
Object{
ObjectOperation permitted-operations<0..*>;
JSONObject permitted-objects;
JSONObject permitted-clients;
JSONNumber expiration-time;
JSONNumber priority;
}AuthToken;
Object{
ObjectProperty object-property;
}
Object{
AuthToken token;
}
If the object property set message is valid, the DECADE Server
replies with the following message:
HTTP/1.1 204 NO CONTENT
Content-Length: ***
Content-Type: application/decade-objprop-set-req-ans+json
X-DECADE-Protocol-Version: 1.0
6.3.6. Delete_Data Message
This operation is used to delete objects from a DECADE Server. An
example of the request message is as following:
Wang, et al. Expires September 13, 2012 [Page 15]
Internet-Draft DRP Mar 2012
DELETE /decade/<obj-name> HTTP/1.1
Host: example.com
Content-Length: ***
Content-Type: application/decade-deledata-req+json
X-DECADE-Protocol-Version: 1.0
X-DECADE-TOKEN: DECADE signature
{
"token": XXX;
}
Object{
ObjectOperation permitted-operations<0..*>;
JSONObject permitted-objects;
JSONObject permitted-clients;
JSONNumber expiration-time;
JSONNumber priority;
}AuthToken;
Object{
AuthToken token;
}
An example of the response message is as following:
HTTP/1.1 204 NO CONTENT
Content-Length: ***
Content-Type: application/decade-deledata-req+json
X-DECADE-Protocol-Version: 1.0
6.4. Error Response Messages
The error response messages for the DECADE protocol are described
below:
SUCCESSFUL (200 OK): a message has been processed properly and the
desired operation has completed. If the message is a request for
information, the body will also include the requested information.
NO CONTENT (204 NO CONTENT): The server successfully processed the
request, but is not returning any content.
INVALID SYNTAX (400 Bad Request): Indicates an error in the format of
the message/message body.
VERSION NOT SUPPORTED (400 Bad Request): Invalid version of the
protocol or message bodies.
AUTHENTICATION REQUIRED (401 UNAUTHORIZED): Authentication is
Wang, et al. Expires September 13, 2012 [Page 16]
Internet-Draft DRP Mar 2012
required to access this information.
MESSAGE FORBIDDEN (403 FORBIDDEN): The requester is not allowed to
make this request.
OBJECT NOT FOUND (404 NOT FOUND): The requested object cannot be
found.
SERVER NOT FOUND (404 NOT FOUND): The requested server cannot be
found.
7. Integration with an HTTP-based SDT
7.1. Put_Object Message
This operation is used to write objects to a DECADE Server. An
example of the request message is as following:
PUT /decade/<obj-name> HTTP/1.1
Host: example.com
Content-Length: ***
Content-Type: application/decade-putdata-req+json
X-DECADE-Protocol-Version: 1.0
X-DECADE-TOKEN: DECADE signature
{
"object-list":
[
"data-object":
{
"object-size": ***;
"object-type": XXX;
"object-metadata":
{
"object-type": XXX;
"object-size": ***;
"TTL": ***;
}
}
]
"token": XXX;
}
JSON Object:
Object{
Wang, et al. Expires September 13, 2012 [Page 17]
Internet-Draft DRP Mar 2012
JSONNumber object-size; [OPTIONAL]
JSONString object-type; [OPTIONAL]
JSONObject object-metadata: [OPTIONAL]
{
JSONString owner;
JSONNumber TTL; [OPTIONAL]
}
}DataObject;
Object{
JSONArray object-list["DataObject"];
}
Object{
ObjectOperation permitted-operations<0..*>;
JSONObject permitted-objects;
JSONObject permitted-clients;
JSONNumber expiration-time;
JSONNumber priority;
}AuthToken;
Object{
AuthToken token;
}
An example of response message is as below:
HTTP/1.1 204 NO CONTENT
Content-Length: ***
Content-Type: application/decade-putdata-ans+json
X-DECADE-Protocol-Version: 1.0
7.2. Get_Object Message
This operation is used to download objects from a DECADE Server. An
example of the request message is as following:
Wang, et al. Expires September 13, 2012 [Page 18]
Internet-Draft DRP Mar 2012
POST /decade/<obj-name> HTTP/1.1
Host: example.com
Content-Length: ***
Content-Type: application/decade-getdata-req+json
X-DECADE-Protocol-Version: 1.0
X-DECADE-TOKEN: DECADE signature
{
"token": XXX;
}
Object{
ObjectOperation permitted-operations<0..*>;
JSONObject permitted-objects;
JSONObject permitted-clients;
JSONNumber expiration-time;
JSONNumber priority;
}AuthToken;
Object{
AuthToken token;
}
An example of the response message is as following:
HTTP/1.1 200 OK
Host: example.com
Content-Length: ***
Content-Type: application/decade-getdata-req+json
X-DECADE-Protocol-Version: 1.0
X-DECADE-TOKEN: DECADE signature
8. Remote_Get_Object Message
This operation is used to download objects from a remote DECADE
server via another DECADE server. The only difference between
Remote_Get_Object and Get_Object is that in the request of the
former, the client should indicate the address of the remote DECADE
server with X-DECADE-ORIGIN header. For example, "X-DECADE-ORIGIN:
origin.com" header in the request shows it is a Remote_Get_Object
request and the remote DECADE server is "origin.com".
9. Security Considerations
The security considerations described in both [I-D.ietf-decade-arch]
and [I-D.ietf-decade-problem-statement] apply to this draft as well.
Wang, et al. Expires September 13, 2012 [Page 19]
Internet-Draft DRP Mar 2012
10. IANA Considerations
This draft does not have any IANA considerations.
11. Acknowledgments
We would like to express our sincere thanks and appreciation to Zhou
Hong for his valuable suggestions and support.
12. References
12.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn , "The
Kerberos Network Authentication Service (V5)", July 2005.
[RFC2865] Rigney, C., Willens, S., Rubens A., A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", June 2000.
[RFC3588] Calhoun , P., Loughney , J., Rubens A., E., Zorn , G., and
J. Arkko, "Diameter Base Protocol", September 2003.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", June 1999.
12.2. Informative Reference
[I-D.ietf-decade-reqs]
Gu, Y., Bryan, D., Yang, Y., and R. Alimi, "DECADE
Requirements", September 2011.
[I-D.ietf-decade-arch]
Alimi , R., Yang, Y., Rahman, A., Kutscher, D., and H.
Liu, "DECADE Architecture", July 2011.
[I-D.ietf-decade-problem-statement]
Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
Application Data Enroute (DECADE) Problem Statement".
Wang, et al. Expires September 13, 2012 [Page 20]
Internet-Draft DRP Mar 2012
[I-D.ietf-oauth-protocol-v2-23]
Recordon, D. and D. Hardt, "The OAuth 2.0 Authorization
Protocol", January 2012.
Authors' Addresses
Wang Danhua
Huawei Technologies
No. 101 Software Avenue
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-56624734
Fax: +86-25-56624702
Email: wangdanhua@huawei.com
Harry Liu
Yale University
Email: hongqiang.liu@yale.edu
Y.Richard Yang
Yale University
Email: yry@cs.yale.edu
Wang, et al. Expires September 13, 2012 [Page 21]