idnits 2.17.1 draft-wang-decade-drp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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]. -- The document date (July 16, 2012) is 4301 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-decade-arch-03' is mentioned on line 122, but not defined == Missing Reference: 'I-D.ietf-decade-reqs-04' is mentioned on line 121, but not defined == Missing Reference: 'I-D.ietf-decade-arch-02' is mentioned on line 152, but not defined == Missing Reference: 'RFC 2865' is mentioned on line 237, but not defined == Missing Reference: 'RFC 2866' is mentioned on line 237, but not defined == Missing Reference: 'RFC 3588' is mentioned on line 237, but not defined ** Obsolete undefined reference: RFC 3588 (Obsoleted by RFC 6733) == Missing Reference: 'OPTIONAL' is mentioned on line 761, but not defined == Missing Reference: 'I-D.ieft-decade-problem-statement' is mentioned on line 870, but not defined == Unused Reference: 'RFC2865' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC2866' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-decade-reqs' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-decade-problem-statement' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-oauth-protocol-v2-23' is defined on line 918, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- No information found for draft-ietf-oauth-protocol-v2-23 - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wang 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track H. Liu 5 Expires: September 13, 2011 Y. Yang 6 Yale University 7 July 16, 2012 9 An HTTP-based Decade Resource Protocol 10 draft-wang-decade-drp-04 12 Abstract 14 This document explorers the design of an HTTP-based DECADE Resource 15 Protocol (DRP), which can be used for content and resource management 16 between a DECADE Client and a DECADE Server, or between two DECADE 17 Servers. We identify the function entities, and present initial 18 protocol message flow and syntax design. The purpose of this 19 document is to get design discussion started, not to provide a 20 complete solution. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 13, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Function Entities . . . . . . . . . . . . . . . . . . . . 4 61 3.3. Protocol Architecture . . . . . . . . . . . . . . . . . . 4 62 3.4. Object Naming . . . . . . . . . . . . . . . . . . . . . . 4 63 3.5. Protocol Operations . . . . . . . . . . . . . . . . . . . 4 64 4. Access and Resource Control . . . . . . . . . . . . . . . . . 5 65 5. Token Structure/HTTP Authentication Format . . . . . . . . . . 6 66 6. Message Syntax and Processing . . . . . . . . . . . . . . . . 7 67 6.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.2. Common Message Processing . . . . . . . . . . . . . . . . 7 69 6.3. DECADE Messages . . . . . . . . . . . . . . . . . . . . . 8 70 6.3.1. Transport_Query Message . . . . . . . . . . . . . . . 8 71 6.3.2. Access_Token Message . . . . . . . . . . . . . . . . . 9 72 6.3.3. Server_States_Query Message . . . . . . . . . . . . . 10 73 6.3.4. Object_Property_Query Message . . . . . . . . . . . . 12 74 6.3.5. Object_Property_Set Message . . . . . . . . . . . . . 14 75 6.3.6. Delete_Data Message . . . . . . . . . . . . . . . . . 15 76 6.4. Error Response Messages . . . . . . . . . . . . . . . . . 16 77 7. Integration with an HTTP-based SDT . . . . . . . . . . . . . . 17 78 7.1. Put_Object Message . . . . . . . . . . . . . . . . . . . . 17 79 7.2. Get_Object Message . . . . . . . . . . . . . . . . . . . . 18 80 8. Remote_Get_Object Message . . . . . . . . . . . . . . . . . . 19 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 12.1. Normative Reference . . . . . . . . . . . . . . . . . . . 21 86 12.2. Informative Reference . . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 The DECADE Architecture document [I-D.ietf-decade-arch-03] identifies 92 a DECADE architecture that consists of two logically independent 93 protocols: the DECADE Resource Protocol (DRP) and the Standard Data 94 Transport (SDT). The former provides access control and resource 95 scheduling between two DECADE peers, while the latter is used to 96 transfer data objects to and from a DECADE Server. The architecture 97 document observes that the two protocols may be realized on the same 98 wire. 100 In this document, we present an initial design of a DRP based on 101 HTTP. We use the DECADE requirements [I-D.ietf-decade-reqs-04] to 102 guide our design. The purpose of this document is to get design 103 discussions started, not to provide a complete solution. 105 Specifically, the DRP we present provides a signaling layer for 106 transport negotiation, content management, access control and 107 resource control. The SDT is responsible for data put, retrieve, 108 delete, and metadata update, and the implementation of access control 109 and resource control policies. 111 We also show that the HTTP based DRP may be extended to include an 112 HTTP based SDT, achieving a same-wire design, although it is also 113 possible to use another SDT. 115 2. Terminologies and concepts 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "MAY", "MAY NOT" and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 This draft uses the terms defined in [I-D.ietf-decade-reqs-04] and in 122 [I-D.ietf-decade-arch-03]. 124 DECADE peers: Entities involved in the DRP, such as a DECADE Server 125 or a DECADE Client. 127 3. Protocol Overview 129 3.1. Overview 131 The DECADE Protocol is spoken between a DECADE Client and a DECADE 132 Server or between two DECADE Servers to manage, store, and retrieve 133 data objects for data distribution. A DECADE Client can be an 134 application server, or embedded in a web browser, etc. 136 We use the scheme where DECADE uses a data-derived naming scheme to 137 achieve content security and de-duplication. In this initial design, 138 we assume that the name space is flat for simplicity. We anticipate 139 that the naming scheme may allow for group operations on a set of 140 data objects with a similar/same attribute. 142 3.2. Function Entities 144 We consider two primary function entities involved in DECADE: the 145 DECADE Server and the DECADE Client. 147 DECADE Server: A DECADE Server stores DECADE data inside the network, 148 and thereafter manages both the stored data and access to that data 149 [I-D.ietf-decade-arch-02]. 151 DECADE Client: A DECADE Client stores and retrieves data at DECADE 152 Servers [I-D.ietf-decade-arch-02]. 154 3.3. Protocol Architecture 156 Figure 1 presents the simple protocol architecture. 157 +------+ DRP +------+ 158 |DECADE|<--------------->|DECADE| 159 |Server|<--------------->|Server| 160 +------+ SDT +------+ 161 ^ ^ ^ ^ 162 | | | | 163 DRP| | SDT DRP| |SDT 164 | | | | 165 v v v v 166 +------+ +------+ 167 |DECADE| |DECADE| 168 |Client| |Client| 169 +------+ +------+ 170 Figure1 Protocol Architecture 172 3.4. Object Naming 174 (To be added...) 176 3.5. Protocol Operations 178 The DRP we present is a request-response protocol. Requests and 179 corresponding responses are exchanged between a DECADE Client and a 180 DECADE Server or between two DECADE Servers. A request includes an 181 Access Token, which allows the DECADE Server to limit access and 182 implement resource control. In particular, a token specifies 183 permitted operations to permitted objects by permitted clients during 184 permitted period, as well as priority for bandwidth given to 185 requested operation, and so on. 187 In particular, we identify the following management requests: 189 Query Server Status (from the system's view): This operation 190 allows a DECADE Client to query statue information of a specific 191 DECADE Server from the server view, e.g., lists of associated 192 objects, resource used/available, and so on. 194 Query Server Status (from the user's view): This operation allows 195 a DECADE Client to query status specific to itself, e.g., list of 196 associated objects that the DECADE Client stored in the Server, 197 the Client's available resources, and so on. 199 Query Object Property: This operation allows a DECADE Client to 200 query object properties, including TTL of objects, object sizes. 202 Set Object Property: This operation allows a DECADE Client to set 203 data object properties. 205 Delete Data Object: This operation is used to delete data objects 206 from a DECADE Server. 208 Complementing the preceding DRP operations, we define the following 209 SDT operations archieve a complete DECADE Protocol: 211 Put Data Object: This operation is used to write data objects to a 212 DECADE Server. 214 Get Data Object: This operation is used to download data objects 215 from a DECADE Server. 217 4. Access and Resource Control 219 We start with a brief evaluation on the feasibility of using an 220 existing IETF protocol for resource control in DECADE. In 221 particular, we evaluate the feasibility of extending an existing 222 protocol for granting a third party access to the resource and data 223 objects owned by a resource/data owner. We consider the 224 applicability of OAuth, AAA, and Kerberos. 226 In Kerberos [RFC4120], a client obtains Tickets to obtain services. 227 Specifically, in Kerberos, a client first obtains a Client/TGS 228 session key and a Ticket-Granting-Ticket from an authentication 229 server. An issue of this approach, however, is that it requires a 230 client to authenticate with the system. Hence, it may work well in a 231 single DECADE domain system where each client has an account at a 232 DECADE provider. On the other hand, DECADE should also work in an 233 inter-domain setting, where a client may not have an account on a 234 Wang, et al. Expires September 13, 2012 [Page 5] Internet-Draft DRP 235 Mar 2012 DECADE server. Hence, extensions could be challenging. 237 Radius [RFC 2865] [RFC 2866] and its successor Diameter [RFC 3588] 238 are the base AAA protocols. Although extending the binary attribute- 239 value-pairs (AVPs) may be possible to grant network resources for 240 data access, the resource control communication points in the DECADE 241 environment are application clients/servers and DECADE servers, and 242 hence a text-based protocol may be preferred by the application 243 clients. However, this should not prevent that the Diameter protocol 244 be used between a DECADE server and an application server for AAA 245 purposes. 247 OAuth v2 [draft-ietf-oauth-protocol-v2-23] is used to grant access to 248 the resource owner's resources from a third party without explicitly 249 exposing the resource owner's credentials. It currently focuses on 250 the context of HTTP [RFC2616]. The three-leg-style access assumption 251 is different from the access requirement in the DECADE system 252 environment. Howerver, some grant types may be adopted (such as 253 implicit grant) and extensions can be added for resource control. 255 5. Token Structure/HTTP Authentication Format 257 A primary use case for DECADE is that a DECADE Client authorizes 258 other DECADE Clients to store or retrieve data objects from its 259 DECADE storage. Therefore, we explore a DECADE protocol using a 260 token-based authorization scheme instead of explicitly manipulating 261 an Access Control List (ACL) for each DECADE data object. 263 Tokens can be generated by a DECADE Client itself or any of its 264 trusted parties/entities. After a token has been generated, it can 265 be distributed to other DECADE Clients for them to request for access 266 to the DECADE Server. In this way, token can support anonymous 267 access, and a DECADE Server does not need to know the identity of 268 each DECADE Client that accesses it. 270 In order to provide a complete authorization scheme, the token MUST 271 carry the following information: Permitted operations, Permitted 272 objects, Permitted Clients, Expiration time, Priority for bandwidth 273 given to requested operation, and Amount of data that may be read or 274 written. 276 The token can be carried with the request message. A possibility of 277 a header for signature is: 279 X-DECADE-TOKEN: DECADE keyID;signature 281 The "signature" represents alphanumeric or numeric data to be 282 inserted, which includes necessary authentication information 283 described before. A design is that the siganture is calculated based 284 on HMAC-SHA1. 286 signature = Base64(HMAC-SHA1(UTF-8-Encoding-Of(StringToSign))) 288 StringToSign = PermittedOperation1 + "\n" + ... + PermittedOperationm 289 + "\n" + PermittedObject1 + "\n" + ... + PermittedObjectn + "\n" + 290 TTL + "\n" + Priority for bandwidth given to requested operation + 291 "\n" + Amount of data that may be read or written + "\n"key 293 After the DECADE Server receives a request, it verifies the 294 authorization by checking the token. If the token is valid, the 295 request/certain operations will be authenticated, otherwise, it will 296 be rejected. If the token is successfully validated, the DECADE 297 Server applies the resources control policies indicated in the token 298 while performing the operation. 300 6. Message Syntax and Processing 302 We now present the encoding and processing. 304 6.1. Encoding 306 The DRP in this document follows the standard request and response 307 formats for HTTP Request and Response messages [RFC2616]. 309 Specifically, the header fields in both request and response messages 310 follows the standard rules for HTTP/1.1 Header fields, which MAY be 311 included in the messages if necessary. 313 We use JSON to encode the bodies for both request and response 314 messages. 316 In the following messages, both *** and XXX represent data to be 317 insert, either numeric data or alphanumeric data. 319 6.2. Common Message Processing 321 After receiving a DECADE protocol message, a DECADE server performs 322 some basic processing, regardless of the message type and the 323 receiving entity. 325 Specifically, upon receiving a message, the DECADE server ensures 326 that the message is properly formed. If not, appropriate standard 327 HTTP errors MUST be generated. Below are some examples. 329 If the message is found to be incorrectly formed or the length does 330 not match the length encoded in the header, the receiver MUST reply 331 with an HTTP 400 response. 333 If the version number is not supported by the receiver, the receiver 334 MUST reply with an HTTP 400 response. 336 If the receiver is unable to process the message temporarily because 337 it is in an overloaded state, the receiver SHOULD reply with an HTTP 338 503 response. 340 If the receiver encounters an internal error while attempting to 341 process the message, the receiver MUST generate an HTTP 500 response. 343 6.3. DECADE Messages 345 DECADE protocol can be divided into two layers, the signaling layer 346 and the transport layer. The signaling layer is responsible for 347 transport negotiation, data management, access control and resource 348 control. The Transport layer is responsible for data put, retrieve, 349 delete, metadata update, and the implementation of access control and 350 resource control policies. Therefore, SDT messages must be extended 351 to include tokens. 353 6.3.1. Transport_Query Message 355 A Transport_Query message is used to query a DECADE server about its 356 supported transports. A DECADE client will send a request to the 357 DECADE server to ask for the transport protocols supported by the 358 server. And then the DECADE server will send back a reply with the 359 supported transport protocols. A DECADE server must listen on the 360 server ports of the supported protocols (e.g. NFS). By that, the 361 DECADE client (active) can impose data operations on the DECADE 362 server using either one of the supported transport protocols 363 supported by the DECADE server. Below is an example Transport_Query 364 message: 365 GET /decade/transport/ HTTP/1.1 366 Host: example.com 367 Content-Length: *** 368 Content-Type: application/decade-transport-req+json 369 X-DECADE-Protocol-Version: 1.0 371 If the query message is valid, the DECADE Server sends back a 372 response listing the supported SDT protocols. An example is shown 373 below: 375 HTTP/1.1 200 OK 376 Content-Length: *** 377 Content-Type: application/decade-transport-ans+json 378 X-DECADE-Protocol-Version: 1.0 380 { 381 "transport-protocol": 382 { 383 "HTTP": true; 384 "NFS": true; 385 "WebDAV": true; 386 } 387 } 389 JSON Object: 390 Object { 391 JSONBool HTTP; [OPTIONAL] 392 JSONBool NFS; [OPTIONAL] 393 JSONBool WebDav; [OPTIONAL] 394 } TransportProtocol; 396 Object { 397 TransportProtocol transport-protocol; 398 } 400 When the DECADE Client receives the response from the Server, it will 401 choose a protocol that it supports and communicates with the Server 402 via the chosen protocol. 404 6.3.2. Access_Token Message 406 It is possible for a client to ask a DECADE server to generate a key, 407 instead of generating locally. An example message is as following: 408 POST /decade/token HTTP/1.1 409 Host: example.com 410 Content-Length: *** 411 Content-Type: application/decade-access-token-req+json 412 X-DECADE-Protocol-Version: 1.0 414 { 415 JSONString: DECADEClientId; 416 token parameters 417 } 419 If the DECADE Client identifier is valid and the request message is 420 successfully proceeded, the DECADE Server will reply with the 421 authenticate token. An example of the response message is as below: 423 HTTP/1.1 200 OK 424 Content-Type: application/decade-access-token-ans+json 425 X-DECADE-Protocol-Version: 1.0 427 { 428 JSONString: token; 429 } 431 6.3.3. Server_States_Query Message 433 This operation allows state query. The state can be either system- 434 wide or on a particular user. An example message is: 435 POST /decade/state HTTP/1.1 436 Host: example.com 437 Content-Length: *** 438 Content-Type: application/decade-stat-req+json 439 X-DECADE-Protocol-Version: 1.0 440 X-DECADE-TOKEN: DECADE signature 442 { 443 "state-request": 444 { 445 "StorageUsed": true; 446 "StorageAvailable": true; 447 "BandwidthUsed": true; 448 "BandwidthAvailable": true; 449 "ObjectNum": true; 450 "ObjectList": true; 451 } 453 "user-type": 454 { 455 "System": true; 456 } 458 "token":XXX; 459 } 461 JSON Object: 462 Object{ 463 JSONBool StorageUsed; [OPTIONAL] 464 JSONBool StorageAvailable; [OPTIONAL] 465 JSONBool BandwidthUsed; [OPTIONAL] 466 JSONBool BandwidthAvailable; [OPTIONAL] 467 JSONBool ObjectNum; [OPTIONAL] 468 JSONBool ObjectList; [OPTIONAL] 469 }ServerState; 470 Object{ 471 JSONBool System; [OPTIONAL] 472 JSONBool User; [OPTIONAL] 473 }UserType; 475 Object{ 476 ObjectOperation permitted-operations<0..*>; 477 JSONObject permitted-objects; 478 JSONObject permitted-clients; 479 JSONNumber expiration-time; 480 JSONNumber priority; 481 }AuthToken; 483 Object{ 484 ServerState server-state; 485 } 487 Object{ 488 UserType user-type; 489 } 491 Object{ 492 AuthToken token; 493 } 495 If a state query message is valid, the DECADE Server responses with 496 corresponding server state. If the "user-type" in the message body 497 is "System", then the server should return the status of resource 498 consumption on this server after verifying the user's access right. 499 Usually the right will be authorized to the system administrator. If 500 the "user-type" in the message body is "User", then the server should 501 return the status of resource consumption of this particular user on 502 this server after verifying the user's access right. An example of 503 the Response is as following: 505 HTTP/1.1 200 OK 506 Content-Length: *** 507 Content-Type: application/decade-stat-ans+json 508 X-DECADE-Protocol-Version: 1.0 510 { 511 "server-state": 512 { 513 "storage-used": ***; 514 "storage-available": ***; 515 "bandwidth-used": ***; 516 "bandwidth-available": ***; 517 "object-number": ***; 519 "object-list": 520 [ 521 "data-object": 522 { 523 "object-name":XXX; 524 } 525 ] 526 } 527 } 529 JSON Object: 530 Object{ 531 JSONNumber storage-used; [OPTIONAL] 532 JSONNumber storage-available; [OPTIONAL] 533 JSONNumber bandwidth-used; [OPTIONAL] 534 JSONNumber object-number; [OPTIONAL] 535 JSONArray object-list["DataObject"]; [OPTIONAL] 536 }ServerState; 538 Object{ 539 JSONString object-name; 540 }DataObject; 542 Object{ 543 DataObject data-object; 544 } 546 6.3.4. Object_Property_Query Message 548 This operation allows a DECADE Client to query object properties with 549 certain authentication, including TTL of object, object size, and 550 object type. The request message is as following: 552 POST /decade/object//property HTTP/1.1 553 Host: example.com 554 Content-Length: *** 555 Content-Type: application/decade-objprop-query-req+json 556 X-DECADE-Protocol-Version: 1.0 557 X-DECADE-TOKEN: DECADE signature 559 { 560 "token": XXX; 561 } 563 JSON Object: 564 Object{ 565 ObjectOperation permitted-operations<0..*>; 566 JSONObject permitted-objects; 567 JSONObject permitted-clients; 568 JSONNumber expiration-time; 569 JSONNumber priority; 570 }AuthToken; 572 Object{ 573 AuthToken token; 574 } 576 If the object property query message is valid and successfully 577 proceeded, the DECADE Server replies the request info. An example of 578 the response message is as below: 580 HTTP/1.1 200 OK 581 Content-Length: *** 582 Content-Type: application/decade-objprop-query-ans+json 583 X-DECADE-Protocol-Version: 1.0 585 { 586 "object-property": 587 { 588 "object-type": XXX; 589 "object-size": ***; 590 "owner": XXX; 591 "TTL": ***; 592 } 593 } 595 JSON Object: 596 Object{ 597 JSONString object-type; [OPTIONAL] 598 JSONNumber object-size; [OPTIONAL] 599 JSONString owner; [OPTIONAL] 600 JSONNumber TTL; [OPTIONAL] 601 }ObjectProperty; 603 Object{ 604 ObjectProperty object-property; 605 } 607 6.3.5. Object_Property_Set Message 609 This operation allows a DECADE Client to set object properties 610 (metadata). The request message is as following: 612 PUT /decade//property HTTP/1.1 613 Host: example.com 614 Content-Length: *** 615 Content-Type: application/decade-objprop-set-req+json 616 X-DECADE-Protocol-Version: 1.0 617 X-DECADE-TOKEN: DECADE signature 619 { 620 "object-property": 621 { 622 "TTL": ***; 623 } 625 "token": XXX; 626 } 628 JSON Object: 629 Object{ 630 JSONNumber TTL; [OPTIONAL] 631 }ObjectProperty; 633 Object{ 634 ObjectOperation permitted-operations<0..*>; 635 JSONObject permitted-objects; 636 JSONObject permitted-clients; 637 JSONNumber expiration-time; 638 JSONNumber priority; 639 }AuthToken; 641 Object{ 642 ObjectProperty object-property; 643 } 645 Object{ 646 AuthToken token; 647 } 649 If the object property set message is valid, the DECADE Server 650 replies with the following message: 651 HTTP/1.1 204 NO CONTENT 652 Content-Length: *** 653 Content-Type: application/decade-objprop-set-req-ans+json 654 X-DECADE-Protocol-Version: 1.0 656 6.3.6. Delete_Data Message 658 This operation is used to delete objects from a DECADE Server. An 659 example of the request message is as following: 661 DELETE /decade/ HTTP/1.1 662 Host: example.com 663 Content-Length: *** 664 Content-Type: application/decade-deledata-req+json 665 X-DECADE-Protocol-Version: 1.0 666 X-DECADE-TOKEN: DECADE signature 668 { 669 "token": XXX; 670 } 672 Object{ 673 ObjectOperation permitted-operations<0..*>; 674 JSONObject permitted-objects; 675 JSONObject permitted-clients; 676 JSONNumber expiration-time; 677 JSONNumber priority; 678 }AuthToken; 680 Object{ 681 AuthToken token; 682 } 684 An example of the response message is as following: 685 HTTP/1.1 204 NO CONTENT 686 Content-Length: *** 687 Content-Type: application/decade-deledata-req+json 688 X-DECADE-Protocol-Version: 1.0 690 6.4. Error Response Messages 692 The error response messages for the DECADE protocol are described 693 below: 695 SUCCESSFUL (200 OK): a message has been processed properly and the 696 desired operation has completed. If the message is a request for 697 information, the body will also include the requested information. 699 NO CONTENT (204 NO CONTENT): The server successfully processed the 700 request, but is not returning any content. 702 INVALID SYNTAX (400 Bad Request): Indicates an error in the format of 703 the message/message body. 705 VERSION NOT SUPPORTED (400 Bad Request): Invalid version of the 706 protocol or message bodies. 708 AUTHENTICATION REQUIRED (401 UNAUTHORIZED): Authentication is 709 required to access this information. 711 MESSAGE FORBIDDEN (403 FORBIDDEN): The requester is not allowed to 712 make this request. 714 OBJECT NOT FOUND (404 NOT FOUND): The requested object cannot be 715 found. 717 SERVER NOT FOUND (404 NOT FOUND): The requested server cannot be 718 found. 720 7. Integration with an HTTP-based SDT 722 7.1. Put_Object Message 724 This operation is used to write objects to a DECADE Server. An 725 example of the request message is as following: 726 PUT /decade/ HTTP/1.1 727 Host: example.com 728 Content-Length: *** 729 Content-Type: application/decade-putdata-req+json 730 X-DECADE-Protocol-Version: 1.0 731 X-DECADE-TOKEN: DECADE signature 733 { 734 "object-list": 735 [ 736 "data-object": 737 { 738 "object-size": ***; 739 "object-type": XXX; 741 "object-metadata": 742 { 743 "object-type": XXX; 744 "object-size": ***; 745 "TTL": ***; 746 } 747 } 748 ] 750 "token": XXX; 751 } 753 JSON Object: 755 Object{ 756 JSONNumber object-size; [OPTIONAL] 757 JSONString object-type; [OPTIONAL] 758 JSONObject object-metadata: [OPTIONAL] 759 { 760 JSONString owner; 761 JSONNumber TTL; [OPTIONAL] 762 } 763 }DataObject; 765 Object{ 766 JSONArray object-list["DataObject"]; 767 } 769 Object{ 770 ObjectOperation permitted-operations<0..*>; 771 JSONObject permitted-objects; 772 JSONObject permitted-clients; 773 JSONNumber expiration-time; 774 JSONNumber priority; 775 }AuthToken; 777 Object{ 778 AuthToken token; 779 } 781 An example of response message is as below: 782 HTTP/1.1 204 NO CONTENT 783 Content-Length: *** 784 Content-Type: application/decade-putdata-ans+json 785 X-DECADE-Protocol-Version: 1.0 787 7.2. Get_Object Message 789 This operation is used to download objects from a DECADE Server. An 790 example of the request message is as following: 792 POST /decade/ HTTP/1.1 793 Host: example.com 794 Content-Length: *** 795 Content-Type: application/decade-getdata-req+json 796 X-DECADE-Protocol-Version: 1.0 797 X-DECADE-TOKEN: DECADE signature 799 { 800 "token": XXX; 801 } 803 Object{ 804 ObjectOperation permitted-operations<0..*>; 805 JSONObject permitted-objects; 806 JSONObject permitted-clients; 807 JSONNumber expiration-time; 808 JSONNumber priority; 809 }AuthToken; 811 Object{ 812 AuthToken token; 813 } 815 An example of the response message is as following: 816 HTTP/1.1 200 OK 817 Host: example.com 818 Content-Length: *** 819 Content-Type: application/decade-getdata-req+json 820 X-DECADE-Protocol-Version: 1.0 821 X-DECADE-TOKEN: DECADE signature 823 8. Remote_Get_Object Message 825 This operation is used to download objects from a remote DECADE 826 server via another DECADE server. The basic idea is to leverage the 827 base functionality of a "non-transparent proxy" in DECADE. In this 828 model, the local DECADE Server would act as a non-transparent caching 829 proxy (with additional functionality) in order to reach the remote 830 DECADE server and cache the contents of the reply in DECADE storage. 831 A general call flow among the DECADE Client, local DECADE Server, and 832 remote DECADE Server is shown in Figure 2. 834 DECADE Client Local DECADE Server Remote DECADE Server 835 (non-transparent proxy) 836 | HTTP Get/Post | | 837 |------------------------>| HTTP Get/Post | 838 | |------------------------->| 839 | | | 840 | |<-------------------------| 841 | | HTTP Response | 842 |<------------------------| | 843 | HTTP Response | | 844 | | | 845 Figure2 Call Flow in Remote_Get_Object Message 847 If DECADE is using HTTP URI types that existing proxies understand, 848 HTTP-Get should be used. If the non-HTTP URI types are used, it'd 849 better to use POST and to provide DECADE request parameters such as 850 the object name in form data parameters. It can cache responses to 851 those requests using cache-control headers. 853 As for server-server communications (without a DECADE Client 854 involved), standard HTTP GET, PUT, POST could be used. Figure 3 855 gives a simple call flow between two DECADE Servers for server-server 856 communications. 857 DECADE Server-1 DECADE Server-2 858 | | 859 | HTTP Get/Post/Put | 860 |--------------------------->| 861 | | 862 |<---------------------------| 863 | HTTP Response | 864 | | 865 Figure3 Call Flow in Server-Server Communications 867 9. Security Considerations 869 The security considerations described in both [I-D.ietf-decade-arch] 870 and [I-D.ieft-decade-problem-statement] apply to this draft as well. 872 10. IANA Considerations 874 This draft does not have any IANA considerations. 876 11. Acknowledgements 878 We would like to express our sincere thanks and appreciation to Zhou 879 Hong for his valuable suggestions and support. 881 12. References 883 12.1. Normative Reference 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", March 1997. 888 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn , "The 889 Kerberos Network Authentication Service (V5)", July 2005. 891 [RFC2865] Rigney, C., Willens, S., Rubens A., A., and W. Simpson, 892 "Remote Authentication Dial In User Service (RADIUS)", 893 June 2000. 895 [RFC2866] Rigney, C., "RADIUS Accounting", June 2000. 897 [RFC3588] Calhoun , P., Loughney , J., Rubens A., E., Zorn , G., and 898 J. Arkko, "Diameter Base Protocol", September 2003. 900 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 901 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 902 Transfer Protocol -- HTTP/1.1", June 1999. 904 12.2. Informative Reference 906 [I-D.ietf-decade-reqs] 907 Gu, Y., Bryan, D., Yang, Y., and R. Alimi, "DECADE 908 Requirements", September 2011. 910 [I-D.ietf-decade-arch] 911 Alimi , R., Yang, Y., Rahman, A., Kutscher, D., and H. 912 Liu, "DECADE Architecture", July 2011. 914 [I-D.ietf-decade-problem-statement] 915 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 916 Application Data Enroute (DECADE) Problem Statement". 918 [I-D.ietf-oauth-protocol-v2-23] 919 Recordon, D. and D. Hardt, "The OAuth 2.0 Authorization 920 Protocol", January 2012. 922 Authors' Addresses 924 Wang Danhua 925 Huawei Technologies 926 No. 101 Software Avenue 927 Nanjing, Jiangsu Province 210001 928 P.R.China 930 Phone: +86-25-56624734 931 Fax: +86-25-56624702 932 Email: wangdanhua@huawei.com 934 Harry Liu 935 Yale University 937 Email: hongqiang.liu@yale.edu 939 Y.Richard Yang 940 Yale University 942 Email: yry@cs.yale.edu