SSD 2 - "Shady Internet Media Protocol (SIMP)" [http://www.shadyindustries.com/specs/ssd/ssd2.txt] Contents: 1 .... Introduction 1.1 ......... Abstract 1.2 ......... Terminology 1.3 ......... Implemenation Information 1.4 ......... Advantages of SIMP 2 .... Headers 2.1 ......... Header syntax 2.2 ......... Extensibility of headers 2.3 ......... Header examples 2.4 ......... Standard headers 2.4.1 .............. SIMP header 2.4.2 .............. STATUS header 2.4.3 .............. ORIGIN header 2.4.4 .............. TYPE header 2.4.5 .............. ACTION header 2.4.6 .............. FILE header 2.4.7 .............. AUTH header 2.4.8 .............. DIGEST header 2.4.9 .............. BODY pseudo-header 2.4.10 .............. ENCODE header 2.4.11 .............. REDIRECT header 2.4.12 .............. DATE header 2.5.1 ......... Encoding of invalid Header Values 2.5.2 ......... Unsupported encoding methods 3 .... STATUS header Values 3.1 ......... 1xx and 2xx families 3.2 ......... 3xx family 3.2.1 .............. 300 - Document Returned 3.2.2 .............. 301 - File Created 3.2.3 .............. 302 - Folder Created 3.2.4 .............. 303 - File Deleted 3.2.5 .............. 304 - Folder Deleted 3.2.6 .............. 305 - File Updated 3.3 ......... 4xx family 3.3.1 .............. 400 - Unsupported SIMP version 3.3.2 .............. 401 - Unauthorised 3.3.3 .............. 402 - Unsupported encoding method 3.3.4 .............. 403 - Invalid Type 3.3.5 .............. 404 - Invalid File/Folder name 3.3.6 .............. 405 - Invalid URI 3.3.7 .............. 406 - DIGEST mismatch 3.3.8 .............. 407 - Syntax Error 3.3.9 .............. 408 - Other Error 3.4 ......... 5xx family 3.4.1 .............. 500 - Resource Not Found 3.4.2 .............. 501 - Resource Moved 3.4.3 .............. 502 - Resource is Empty 3.4.4 .............. 503 - Folder does not exist 3.4.5 .............. 504 - File does not exist 3.4.6 .............. 505 - Folder already exists 3.4.7 .............. 506 - File already exists 3.4.8 .............. 507 - Forbidden 3.4.9 .............. 508 - Unsupported Command 3.4.10 .............. 509 - Other Error 4 .... ACTION header Values 4.1 ......... GET 4.2 ......... CRTFILE 4.3 ......... DELFILE 4.4 ......... CRTFOLDER 4.5 ......... DELFOLDER 4.6 ......... REPLACE 5 .... Appendices 5.1 ......... Security Considerations 5.2 ......... Integrity Considerations 5.3 ......... Interoperability Considerations 5.4 ......... Encoding Considerations 5.5 ......... Full SIMP examples 5.5.1 .............. STATUS code 300 5.5.2 .............. STATUS code 402 5.5.3 .............. STATUS code 501 5.5.4 .............. ACTION command GET 5.5.5 .............. ACTION command CRTFOLDER 5.5.6 .............. ACTION command REPLACE 5.6 ......... SIMP Media Type 5.7 ......... External Sources 5.8 ......... Authors 1.1 Abstract This document specifies the standard used for the Shady Internet Media Protocol, or SIMP, data transfer protocol. SIMP is intended to be used in a similar manner to the popular HTTP Protocol [1], but is specifically designed to cater to the extensibility, platform neutrality, and simplicity required by modern systems, particularly handheld devices and internal networks. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [2] and indicate requirement levels for implementations compliant with this specification. 1.3 Implementation Information SIMP is an application (layer 7) protocol in the OSI model [9], with some elements of the presentation layer (layer 6). This puts it in a similar position to the HTTP protocol [1] that it is intended to be used in the place of. SIMP can be used over any transport protocol that has a packet-ordering facility. 1.4 Advantages of SIMP The main advantage that SIMP has over HTTP is it's simplicity. HTTP has a large feature set, much of which is rarely used. SIMP fulfills the most common functions of HTTP and still retains some of the less used (but useful) functions of HTTP, but has far fewer features, and a simple, consistent syntax, making it easier to implement. SIMP is particularly well suited to situations in which HTTP-like functionality is required, without the processing and storage overhead required for the larger HTTP libraries, for example in a server-farm in which servers are constantly updating each other's files. 2.1 Header syntax Headers MUST be terminated by a CRLF combination, and consist of two parts: the Name and the Value. The Name is a character string that identifies a header, and MUST be unique throughout the SIMP document's Header Names. The Header Name MUST be comprised only of the following ASCII characters: 48-57, 65-90, 97-122, 95, 45 and 43. The Name always appears directly after a CRLF combination or at the beginning of the SIMP document. The Name is separated from the Value by a single space (ASCII 32), and the Value can be any visible ASCII character string, unless it contains ASCII 60, 13, or 10 in which case the Value MUST be encoded according to section 2.5. 2.2 Extensibility of headers Custom headers may be specified by adding an "X-" to the beginning of the Header Name. If a SIMP parser encounters a Header with a Name beginning with "X-" that it does not understand, the Header SHOULD be ignored. If the parser encounters a header it does not understand and the Header Name does not begin with an "X-", processing of the document must be terminated. If a SIMP parser encounters a Header Name comprised of invalid characters, the Header SHOULD be discarded and processing SHOULD continue. Headers with the same Name MUST NOT appear twice in the same SIMP document. Headers with no Value SHOULD be ignored by a SIMP parser. Header Names MUST be parsed case-insensitively. 2.3 Example Headers Example 1 (Valid): "TEST HELLO" ^ ^ ^ | | Value | Separator Name Example 1 (Invalid): "/TEST HELLO" ^ ^ ^ | | Value | Separator Invalid Name Example 2 (Invalid): "TEST HELLO < to YOU!!" ^ ^ ^ | | Invalid Character in Value | Separator Name Example 2 (Valid): "TEST <16>48454C4C4F203C20746F20594F552121" ^ ^ ^ | | Encoded Value (See section 2.5) | Separator Name 2.4 Standard headers This is an exhaustive list of all standard headers for SIMP 1.0 2.4.1 SIMP header All valid SIMP documents MUST begin with a SIMP header. The SIMP header's value is the version number of the SIMP protocol being used, for example: "SIMP 1.0" Implementers MUST NOT assume this header's value will always be "1.0". Servers SHOULD return SIMP documents of the same version as the client's initial request. Clients SHOULD use the most appropriate version of SIMP, which in many cases will be the most recent. 2.4.2 STATUS header The STATUS header describes the type of response issued by a server. This Header SHOULD only appear in SIMP documents that originate at a server. If a server receives this header from a client, the server SHOULD disregard the header. The header's value is a 3-digit integer. For example: "STATUS 100" An exhaustive list the STATUS Header's Value codes is provided in section 3. 2.4.3 ORIGIN header The ORIGIN header describes the origin of the SIMP response or request. The ORIGIN header's value is split into two sections, separated by a single space (ASCII 32). The first section is the domain name or IP address of the originating Server or Client, and the second is an open port number that can be used to send SIMP requests/responses to. An ORIGIN header from a server might look like: "ORIGIN domain.tld 49000" Or with a subdomain: "ORIGIN subdomain.domain.tld 39182" 2.4.4 TYPE header The TYPE header specifies the MIME Media Type [4] for the data contained in the BODY pseudo-header. The TYPE header value MUST be a valid Media Type. The TYPE header is used to identify how a document should be processed by a client, and is also used in conjunction with the ACTION header (see sections 2.4.5 and 4). The TYPE header MUST NOT appear in any SIMP document where a BODY pseudo-header is not also present. An example TYPE header: "TYPE text/plain; charset=UTF-8" 2.4.5 ACTION header The ACTION header specifies to a server how to process the SIMP request, and MUST appear in any SIMP document that originated at a client. A Client SHOULD disregard any ACTION header from a server, if it receives one. An exhaustive list of ACTION header Values, and their related behaviours is in section 4. 2.4.6 FILE header If the FILE header is in a SIMP document originating at a server, the value MUST be a URI [3] to the requested resource, relative to the root of the domain name specified in the ORIGIN header. If the FILE header is in a SIMP document originating at a client, the value MUST be the original filename of the resource being sent. This header SHOULD NOT be present when the SIMP document contains no BODY pseudo-header (see section 2.4.9). For exact use and behaviours of this header when present in a SIMP document originating at a client, see section 4. URIs provided in this header MUST NOT go below the root of the hostname (for example, "../win.ini" is below the root of the hostname, and so is not allowed), if a server receives a FILE header violating this rule, a 405 STATUS code MUST be issued (see section 3.3.6). An example FILE header originating at a server might look like: "FILE folder/file.txt" or from a client: "FILE file.txt" 2.4.7 AUTH header The AUTH header is used by a client to specify a username/password combination to gain access to otherwise restricted resources or commands available on a server. The AUTH header's value is split into two sections, separated by a single space (ASCII 32). The first section is the username, which MUST be comprised only of the ASCII characters: 48-57, 65-90, 97-122, 95, 45 and 43. The second section is the password which may be any visible ASCII character string. If the Password section of the value contains an invalid character, then the entire Value (username, separator and password) must be encoded according to section 2.5. The AUTH header MAY appear in any SIMP document originating at a client, but it SHOULD NOT appear in any SIMP document originating at a server. Any client receiving an AUTH header from a server SHOULD ignore the header. If a command and/or resource does not require authentication to access, the server SHOULD ignore any AUTH header it may encounter. An example AUTH header might look like: "AUTH username password" This is invalid: "AUTH username pass:@@word" This is the above encoded (see section 2.5) to make it valid: "AUTH <16>75736526E616D6520706173733A4040776F7264" 2.4.8 DIGEST header The DIGEST header specifies an MD5 Checksum [5] of the BODY pseudo-header's Value, and is used to ensure that the Value of the BODY pseudo-header has been received correctly The DIGEST header MUST only appear in a SIMP document when the BODY pseudo-header is present. If the DIGEST header's Value does not match the MD5 Checksum of the BODY pseudo-header's Value exactly, the SIMP document SHOULD be re-requested from the source (server or client) by the appropriate method (see section 3.3.7 and section 4.1). This header MUST NOT appear in any SIMP document where a BODY pseudo-header is not present. A DIGEST header might look like: "DIGEST 0bf95790a04073174760d69ff459b26e" 2.4.9 BODY pseudo-header The BODY pseudo-header MUST be the last header in any SIMP document, and is syntactically identical to any normal header, with the exception that its Value MUST always be encoded according to section 2.5. The BODY pseudo-header's Value is the main bulk of data that the rest of the headers describe, and is REQUIRED to be present unless otherwise stated. The termination of the BODY pseudo-header (a CRLF combination) can be taken to mark the end of a SIMP document. If a BODY pseudo-header is present in any SIMP document, a TYPE and DIGEST header MUST also be present. A FILE header MAY also be required depending on the circumstance. A BODY pseudo-header might look like: "BODY <64>SGVsbG8gV29ybGQh" 2.4.10 ENCODE header The ENCODE header MAY appear in any SIMP document, but is NOT REQUIRED. The ENCODE header's Value is one of "16", "32" or "64", and is used to specifically request that all header encoding (see section 2.5) be done in the specified encoding method. For example "ENCODE 32" would request that all responses use the Base-32 [6] encoding method. 2.4.11 REDIRECT header The REDIRECT header MAY appear in any SIMP document that originates at a server, but is NOT REQUIRED. The REDIRECT header's Value MUST be a full URI [3] (including protocol and port). The REDIRECT header is used to tell a client: (1) The new location of a document (see section 3.4.2) (2) To move to the specified URI as soon as possible. If a BODY pseudo-header is present in the same document as a REDIRECT header, the client MAY display the BODY pseudo-header until the redirection has taken place. An example REDIRECT header might look like: "REDIRECT simp://simp.somedomain.tld:5000/folder/file.ext" 2.4.12 DATE header The DATE header is returned with all 300 STATUS codes (see section 3.2.1), and contains a RFC3339 [8] formatted date of when the file was last updated. A DATE header might look like: "DATE Mon, 01 Oct 2007 14:19:20 +0000" 2.5.1 Encoding of invalid Header Values If a Header Value is invalid (see section 2.1) or the Header is the BODY pseudo-header, the entire Value MUST be encoded. The Value MUST be encoded in one of the following three encoding systems: Base-16, Base-32 or Base-64 [6]. The encoded Value is then prefixed with a control code to indicate the encoding used. This control code is delimited by opening and closing angle brackets, and contains the base-number (e.g. 16). The control code for base 16 looks like: "<16>" The control code for base 32 looks like: "<32>" The control code for base 64 looks like: "<64>" A complete Base-64 encoded value might look like: "<64>SGVsbG8gV29ybGQh" 2.5.2 Unsupported encoding methods If a client does not support one or more encoding methods, it SHOULD use the ENCODE header (see section 2.4.10) to tell the server to use only a supported encoding method. If a server does not support an encoding method, it MUST issue a 402 STATUS header (see section 3.3.3) in response to a SIMP document containing unsupported encoding(s). 3 STATUS header Values This is an exhaustive list of all STATUS header Value codes, and their associated behaviours. Any unspecified STATUS code is reserved for future specifications. 3.1 1xx and 2xx families These families of STATUS codes are reserved for future specifications. 3.2 3xx family This family of STATUS codes indicate that processing of the requested action was completed successfully. 3.2.1 300 - Document Returned This STATUS code indicates that the requested resource has been returned in the BODY pseudo-header, and that further communication between the client and server is NOT REQUIRED. This STATUS code MUST only occur in response to a client's GET ACTION (see section 4.1). The use of a DATE header is RECOMMENDED, and MUST contain an RFC3339 [8] formatted date of when the file was last updated. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, TYPE, FILE, DIGEST, BODY The following headers MUST NOT be present: REDIRECT, ACTION, ENCODE, AUTH RECOMMENDED headers: DATE 3.2.2 301 - File Created This STATUS code indicates that the requested file has been created, and that further communication between the client and server is NOT REQUIRED. The FILE header in this instance MUST contain a relative URI to the newly created file. This STATUS code MUST only occur in response to a client's CRTFILE ACTION (see section 4.2). The initial contents of the file MAY be returned in a BODY pseudo-header. Additionally, a REDIRECT header MAY be used. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY, REDIRECT 3.2.3 302 - Folder Created This STATUS code indicates that the requested folder has been created, and that further communication between the client and server is NOT REQUIRED. The FILE header in this instance MUST contain a relative URI to the newly created folder. This STATUS code MUST only occur in response to a client's CRTFOLDER ACTION (see section 4.4). A REDIRECT header MAY be used. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY, REDIRECT 3.2.4 303 - File Deleted This STATUS code indicates that the specified file has been deleted, and that further communication between the client and server is NOT REQUIRED. The FILE header in this instance MUST contain a relative URI to the deleted file. This STATUS code MUST only occur in response to a client's DELFILE ACTION (see section 4.3). A REDIRECT header MAY be used to direct the client to an index or explanation page. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY, REDIRECT 3.2.5 304 - Folder Deleted This STATUS code indicates that the requested folder and all its contents has been deleted, and that further communication between the client and server is NOT REQUIRED. The FILE header in this instance MUST contain a relative URI to the deleted folder. This STATUS code MUST only occur in response to a client's DELFOLDER ACTION (see section 4.5). A REDIRECT header MAY be used to direct the client to an index or explanation page. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY, REDIRECT 3.2.6 305 - File Updated This STATUS code indicates that the contents and/or type of the specified file have updated with the new content and/or type information, and that further communication between the client and server is NOT REQUIRED. The FILE header in this instance MUST contain a relative URI to the updated file. This STATUS code MUST only occur in response to a client's REPLACE ACTION (see section 4.6). The updated content of the file MAY be returned in a BODY pseudo-header. Additionally, a REDIRECT header MAY be used. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY, REDIRECT 3.3 4xx family This family of STATUS codes indicate that processing of the requested action was not completed successfully, and that the error preventing processing can be corrected by the client. Unless expressly forbidden by a STATUS code's individual specification, a BODY pseudo-header MAY be used to contain a human-readable explanation of the precise error that occurred. 3.3.1 400 - Unsupported SIMP version This STATUS code indicates that the version of SIMP used in the SIMP document that the client originally sent is not supported by the server, and that a different version SHOULD be used in subsequent requests. This STATUS code MAY also be used to indicate that no SIMP header was present in the document, though it is RECOMMENDED to use the 407 code (see section 3.3.8). When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN The following headers MUST NOT be present: ACTION, ENCODE, TYPE, DIGEST, BODY, REDIRECT, FILE, AUTH, DATE OPTIONAL headers: N/A 3.3.2 401 - Unauthorised This STATUS code indicates that the AUTH header provided in the client's initial request did not contain the correct details to access the command and/or resource. If no AUTH header was provided, this STATUS code indicates that one is REQUIRED in subsequent requests, because the command and/or resource is under authentication protection. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, REDIRECT, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY 3.3.3 402 - Unsupported encoding method This STATUS code is used to tell a client that their request could not be fulfilled because an unsupported encoding method was used in the initial request. An ENCODE header (see section 2.4.10) is used to indicate a supported encoding method for the client to use in subsequent request. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, ENCODE The following headers MUST NOT be present: ACTION, REDIRECT, FILE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY 3.3.4 403 - Invalid Type This STATUS code MUST be returned if a server has rejected a client's request because the TYPE header contained an invalid or inappropriate Media Type [4]. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN The following headers MUST NOT be present: ACTION, REDIRECT, FILE, ENCODE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY 3.3.5 404 - Invalid File/Folder name This STATUS code MUST be returned by a server if the server has rejected a client's request because the FILE header contained an invalid file or folder name. A BODY pseudo-header is RECOMMENDED in this instance, so the server can point out the exact file or folder name that was invalid – since requests may contain multiple folders and a file. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, REDIRECT, ENCODE, AUTH, DATE RECOMMENDED headers: TYPE, DIGEST, BODY 3.3.6 405 - Invalid URI This STATUS code MUST be returned by a server if the server has rejected a client's request because the FILE header contained an invalid URI. This STATUS code is similar in manner to the 404 (see section 3.3.5) with the difference that the 405 is returned only when a server could not process the FILE header's value since it did not conform to valid URI syntax for the circumstance (normally the FILE header should be relative). This STATUS code MAY be used to inform the client of a malformed or invalid ORIGIN hostname or IP Address, though it is RECOMMENDED that this be done using the 408 code (see section 3.3.9). A BODY pseudo-header is RECOMMENDED, so the server can show the user the exact error(s) in the URI syntax. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, REDIRECT, ENCODE, AUTH, DATE RECOMMENDED headers: TYPE, DIGEST, BODY 3.3.7 406 - DIGEST mismatch This STATUS code is returned by a server when the server has rejected a client's request because the value of the DIGEST header did not match the MD5 Checksum [5] of the value of the BODY pseudo-header. This code is essentially a request for client to re-send its original request, hopefully with a matching DIGEST and BODY. The original TYPE, DIGEST, BODY and FILE (where applicable) data MAY be returned in their unaltered state to allow a client to identify the request that it needs to re-send. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN The following headers MUST NOT be present: ACTION, REDIRECT, ENCODE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY, FILE 3.3.8 407 - Syntax Error This STATUS code is returned when the any part of a SIMP document's overall syntax and structure does not match this version, or subsequent versions, of SIMP specifications. This STATUS code MAY also be used to indicate that no SIMP header was present in the document. The BODY pseudo-header MAY be used to explain the error encountered. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN The following headers MUST NOT be present: ACTION, REDIRECT, ENCODE, FILE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY 3.3.9 408 - Other Error This STATUS code MAY be used for any fatal error not covered by the other 4xx family codes. This code MUST only be used for errors that can be rectified by the client. A full human-readable explanation of the error MUST be included in a BODY pseudo-header. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, TYPE, DIGEST, BODY The following headers MUST NOT be present: ACTION, ENCODE, REDIRECT, FILE, AUTH, DATE OPTIONAL headers: N/A 3.4 5xx family This family of STATUS codes indicate that processing of the requested action was not completed successfully, and that the error preventing processing can be cannot be rectified by the client, or that processing is not yet complete and requires further action by the client. Unless expressly forbidden by a STATUS code's individual specification, a BODY pseudo-header MAY be used to contain a human-readable explanation of the precise error or required action. 3.4.1 500 - Resource Not Found This STATUS code is returned when a resource cannot be located. This code SHOULD only be returned by a server in response to a client's ACTION GET request (see section 4.1). The FILE header MUST be present, and MUST contain the originally requested resource URI. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, REDIRECT, TYPE, DIGEST, BODY, AUTH, DATE OPTIONAL headers: N/A 3.4.2 501 - Resource Moved This STATUS code is returned when a resource that was previously at the requested URI has been moved to a new URI. This code SHOULD only be returned by a server where a 500, 503 or 504 code would otherwise be appropriate. The FILE header MUST be present, and MUST contain the originally requested resource URI. The REDIRECT header MUST be present, containing an absolute URI to the resource's new location. Clients SHOULD redirect themselves to the new URI, and update any saved URIs to the old location to the URI of the new location. A BODY pseudo-header MAY be present, containing a message to be shown to the user by the client until the redirection takes affect (if applicable). When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE, REDIRECT The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE OPTIONAL headers: TYPE, DIGEST, BODY 3.4.3 502 - Resource is Empty This STATUS code is REQUIRED when a requested resource does exist, but has no content. This STATUS code MUST only be used where a 300 code would otherwise be appropriate (see section 3.2.1). This STATUS code is not always an error, but in most instances it will be. It is needed in the specification due to the syntactic limitation that headers cannot be empty (see section 2.1). When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: DIGEST, BODY, ACTION, ENCODE, AUTH, TYPE, DATE OPTIONAL headers: N/A 3.4.4 503 - Folder does not exist This STATUS code is returned when one or more folder(s) in a requested URI do not exist. The FILE header MUST be present, showing the originally requested URI. A BODY pseudo-header is RECOMMENDED, containing a human-readable explanation of the folder or folders missing. This STATUS code MUST NOT be returned when the original client request was of the ACTION type "GET" (see section 4.1). If this is the circumstance, a 500 code (see section 3.4.1) MUST be used where this code would otherwise be appropriate. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE RECOMMENDED headers: DIGEST, BODY, TYPE 3.4.5 504 - File does not exist This STATUS code is returned when the file in a requested URI does not exist. The FILE header MUST be present, showing the originally requested URI. A BODY pseudo-header is RECOMMENDED, containing a human-readable explanation of the non-existent file. This STATUS code MUST only be returned when the original client request was of the ACTION type "DELFILE" or "REPLACE" (see sections 4.3 and 4.6). If this is not the circumstance, a 500 code (see section 3.4.1) MUST be used where this code would otherwise be appropriate. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE RECOMMENDED headers: DIGEST, BODY, TYPE 3.4.6 505 - Folder already exists This STATUS code SHOULD be returned if the folder that a user is attempting to create via a ACTION CRTFOLDER (see section 4.4) request, already exists. This code MUST NOT be used under any other circumstance. A FILE header is REQUIRED, containing the original URI of the folder being created. A BODY pseudo-header is RECOMMENDED, containing human-readable information on the existing folder error. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE RECOMMENDED headers: DIGEST, BODY, TYPE 3.4.7 506 - File already exists This STATUS code SHOULD be returned if the file that a user is attempting to create via a ACTION CRTFILE (see section 4.2) request, already exists. This code MUST NOT be used under any other circumstance. A FILE header is REQUIRED, containing the original URI of the file being created. A BODY pseudo-header is RECOMMENDED, containing human-readable information on the existing file error. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, AUTH, DATE RECOMMENDED headers: DIGEST, BODY, TYPE 3.4.8 507 - Forbidden This STATUS code SHOULD only be used where a 401 (see section 3.3.2) would otherwise be appropriate, and is used to indicate that the request resource or action command is never allowed to be accessed, and that sending an AUTH (see section 2.4.7) header in a subsequent request would therefore be redundant. A BODY pseudo-header MAY be used to give human-readable information about why the resource or command is forbidden. This code SHOULD NOT be used if an ACTION command is not supported, the correct code for that is 508 (see section 3.4.9). When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, FILE The following headers MUST NOT be present: ACTION, ENCODE, REDIRECT, AUTH, DATE OPTIONAL headers: DIGEST, BODY, TYPE 3.4.9 508 - Unsupported Command This STATUS code is to tell the client that an ACTION command (see Section 4) it attempted to use is not supported, or disabled, on the server. An ACTION header MUST be present, containing the name of the unsupported command. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, ACTION The following headers MUST NOT be present: ENCODE, REDIRECT, FILE, DIGEST, BODY, TYPE, AUTH, DATE OPTIONAL headers: N/A 3.4.10 509 - Other Error This STATUS code MAY be used for any fatal error not covered by the other 5xx family codes. This code MUST only be used for errors that cannot be rectified, or can only be rectified by the server administrator. A full human-readable explanation of the error MUST be included in a BODY pseudo-header. When this STATUS code is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, TYPE, DIGEST, BODY The following headers MUST NOT be present: ACTION, ENCODE, REDIRECT, FILE, AUTH, DATE OPTIONAL headers: N/A 4 ACTION header values An ACTION header tells a server how to process the SIMP document it has received from a client. Custom ACTION header values MAY be used provided they begin with "X-". If a server encounters an unsupported or unknown custom command, the 508 STATUS code (see section 3.4.9) is the suitable response. ACTION header Values MUST be processed case-insensitively. 4.1 GET The GET command is used by a client to retrieve data from a server using a request URI. A BODY pseudo-header MAY also be used to submit data that is used by the server during the processing of the request, similar to the POST action of HTTP [1]. It is RECOMMENDED that the Media Type [4] "multipart/form-data" [7] is used to submit form-based data via this mechanism. If a server does not support a particular Media Type used to submit data via a BODY pseudo-header or the data is invalid, the BODY pseudo-header SHOULD be ignored, or alternatively the server MAY issue a 408 error (see section 3.3.9). The FILE header is used with this ACTION command to specify the relative URI to the resource being requested. When this ACTION command is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, ACTION, FILE The following headers MUST NOT be present: REDIRECT, DATE OPTIONAL headers: ENCODE, TYPE, DIGEST, BODY, AUTH 4.2 CRTFILE The CRTFILE command is used by a client to create a new file on the server at the specified URI. If one or more folders in the request URI do not exist, the server SHOULD return a 503 STATUS code (see section 3.4.4), but MAY opt to create the missing folders. If the file the user is attempting to create already exists, a 506 STATUS code (see section 3.4.7) SHOULD be sent in response. The FILE header MUST be present and contain the URI (relative to the root of the hostname) to the file being created. If the file being created is intended to be empty initially, a BODY pseudo-header SHOULD NOT be included, otherwise, the contents of the new file SHOULD be included in a BODY pseudo-header, and a TYPE header is therefore required, and MUST contain the Media Type of the new file. If the file is successfully created, a 301 STATUS code (see section 3.2.2) MUST be returned by the server; if the new file is empty, the 301 STATUS code MUST NOT include a BODY pseudo-header. When this ACTION command is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, ACTION, FILE The following headers MUST NOT be present: REDIRECT, DATE OPTIONAL headers: ENCODE, TYPE, DIGEST, BODY, AUTH 4.3 DELFILE The DELCRTFILE command is used by a client to delete a file on the server at the specified URI. If one or more folders in the request URI do not exist, the server MUST return a 503 STATUS code (see section 3.4.4). If the file the user is attempting to delete does not exist, a 504 STATUS code (see section 3.4.5) MUST be sent in response. The FILE header MUST be present and contain the URI (relative to the root of the hostname) to the file being deleted. If the file is successfully deleted, a 303 STATUS code (see section 3.2.4) MUST be returned by the server. When this ACTION command is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, ACTION, FILE The following headers MUST NOT be present: REDIRECT, TYPE, DIGEST, BODY, DATE OPTIONAL headers: ENCODE, AUTH 4.4 CRTFOLDER The CRTFOLDER command is used by a client to create a new folder on the server at the specified URI. If one or more folders in the request URI do not exist (besides the one being created), the server SHOULD return a 503 STATUS code (see section 3.4.4), but MAY opt to create the missing folders as well. If the folder the user is attempting to create already exists, a 505 STATUS code (see section 3.4.6) SHOULD be sent in response. The FILE header MUST be present and contain the URI (relative to the root of the hostname) to the FOLDER being created. If the folder is successfully created, a 302 STATUS code (see section 3.2.3) MUST be returned by the server. When this ACTION command is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, ACTION, FILE The following headers MUST NOT be present: REDIRECT, TYPE, DIGEST, BODY, DATE OPTIONAL headers: ENCODE, AUTH 4.5 DELFOLDER The DELFOLDER command is used by a client to delete a folder on the server (and all its content and subdirectories) at the specified URI. If one or more folders in the request URI do not exist, the server MUST return a 503 STATUS code (see section 3.4.4). The FILE header MUST be present and contain the URI (relative to the root of the hostname) to the FOLDER being deleted. If the folder and all its subdirectories and files are successfully deleted, a 304 STATUS code (see section 3.2.5) MUST be returned by the server. When this ACTION command is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, ACTION, FILE The following headers MUST NOT be present: REDIRECT, TYPE, DIGEST, BODY, DATE OPTIONAL headers: ENCODE, AUTH 4.6 REPLACE The REPLACE command is used by a client to replace the content of a file (specified with a relative URI) with new content provided in the BODY pseudo-header. If the update is intended to make the file have no content (empty), the BODY pseudo-header MUST NOT be included. The FILE header MUST be present, and contain the relative URI to the file being replaced. If one or more folders in the request URI do not exist, the server MUST return a 503 STATUS code (see section 3.4.4). If the file the user is attempting to replace does not exist, a 504 STATUS code (see section 3.4.5) MUST be sent in response. If the REPLACE operation is successful, a 305 STATUS code is the appropriate response (see section 3.2.6). This ACTION command is also updates the TYPE information on the server at the same time, and so a TYPE header is also REQUIRED (unless the replacement will make the file empty). When this ACTION command is used, the following headers MUST be present: SIMP, STATUS, ORIGIN, ACTION, FILE The following headers MUST NOT be present: REDIRECT, DATE OPTIONAL headers: ENCODE, TYPE, DIGEST, BODY, AUTH 5.1 Security Considerations SIMP makes no attempt to ensure that data is protected from unauthorised view during transit, however, implementations are more than welcome to attempt to layer SSL or another encryption system over SIMP using custom headers. Future versions of the SIMP specification will likely support SSL or a similar data protection system natively. Resources, folders and/or commands can be forbidden (see section 3.4.8) or authentication protected (see sections 3.3.2 and 2.4.7) via SIMP. All of the commands in SIMP could potentially be harmful, if care is not taken to restrict their use, though the GET action (see section 4.1) probably has the least chance of harm as a result of unrestricted use. It is RECOMMENDED that server administrators and server programmers take care to ensure that the commands cannot be used maliciously (for example, deleting or altering system files, or viewing files containing sensitive data). Since SIMP is a transport protocol, it can contain arbitary data of any type, which may include active or executable content. It is entirely up to the implentation to discern malicious content from benign content, and to decide whether to execute the data. It is RECOMMENDED that unless some kind of privacy service, such as SSL, is layered over SIMP that sensitive data not be sent over this version of the SIMP protocol, and that implementations assume all data to be malicious until determined to be otherwise. [This section is subject to constant review and update.] 5.2 Integrity Considerations The content of the BODY pseudo-header (see section 2.4.9) is always accompanied by a DIGEST header (see section 2.4.8) which is used to ensure that the content of the BODY pseudo-header has not been corrupted during transit. All other data in the SIMP document (such as other headers) do not have any method of integrity checking, though it can generally be considered true that if the document does not comply with SIMP syntactic rules (or any other applicable rules, such as URI or Media Type), that it has been corrupted during transit (for example, the first header name being "S@MP" instead of "SIMP"). This version of SIMP makes no attempt to protect against malicious alteration of the document during transit; implementators are welcome to attempt to add such a service using custom headers. [This section is subject to constant review and update.] 5.3 Interoperability Considerations There is not believed to be any reason why this protocol cannot be interpreted or sent correctly on any given system, except when [This section is subject to constant review and update.] 5.4 Encoding Considerations SIMP automatically disallows and encodes any non-ASCII data, and therefore, this protocol can be safely considered to be a 7-bit ASCII protocol, although it can carry encoded data of other character sets. [This section is subject to constant review and update.] 5.5 Full SIMP examples Note that line-breaks within the value of the BODY pseudo-header, and tabs anywhere in any/all examples are to preserve the profile of this document. Also note that a line beginning with #NOTE: is a comment and not part of the actual example. 5.5.1 STATUS code 300 SIMP 1.0 STATUS 300 ORIGIN 127.0.0.1 49000 FILE /index.rtf DATE Tue, 30 Oct 2007 20:35:27 -0400 TYPE text/rtf DIGEST fa604487f802f893a401ffbd48634ea2 BODY <64>e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Y mx7XGYwXGZuaWxcZmNoYXJzZXQwIEx1Y2lkYSBDb25zb2xlO319DQpcdmlld2tpbmQ0XHVjMVx wYXJkXHFjXHVsXGJcZjBcZnMxNDQgSGVsbG8gV29ybGRcdWxub25lXGIwXGZzMTcgDQpccGFyI A0KXHBhciBcaSBUaGlzIGlzIGFuIFJURiBpbmRleCBwYWdlIDpEXGkwIA0KXHBhciB9 5.5.2 STATUS code 402 SIMP 1.0 STATUS 402 ORIGIN simp.shadyindustries.biz 23913 ENCODE 16 TYPE text/enriched; charset=us-ascii DIGEST 60775265e46394153a220728e1dc12bd BODY <16>3C6E6F66696C6C3E3C6269676765723E4572726F72203430323C2F62696767657 23E0D0A0D0A596F75722062726F777365722073656E7420612053494D50207265717565737 420636F6E7461696E696E6720612076616C756520656E636F646564207573696E672074686 52073797374656D20223C6974616C69633E426173652D33323C2F6974616C69633E2220776 8696368206973206E6F7420737570706F727465642062792074686973207365727665722E0 D0A596F75722062726F7773657220686173206265656E20746F6C6420746F2075736520746 86520426173652D313620656E636F64696E6720696E73746561642C20616E642073686F756 C64206E6F74207265717569726520616E79206675727468657220696E74657276656E74696 F6E2066726F6D20796F752E3C2F6E6F66696C6C3E 5.5.3 STATUS code 501 SIMP 1.0 STATUS 501 ORIGIN 127.0.0.1 49000 FILE /ssd/ssd2.txt REDIRECT simp://127.0.0.1:49000/new-ssd/ssd2.txt 5.5.4 ACTION command GET simp 1.0 action GeT oRIgin 192.168.0.5 32000 FILE /index.txt ENCODE 16 auth admin password 5.5.5 ACTION command CRTFOLDER #NOTE: this will create the folder "folder2" inside the folder "folder1" #NOTE: relative to the root of the hostname. SIMP 1.0 ACTION CRTFOLDER ORIGIN 192.168.0.1 31006 FILE /folder1/folder2 5.5.6 ACTION command REPLACE SIMP 1.0 ACTION REPLACE ORIGIN 192.168.0.5 32000 FILE /index.txt ENCODE 64 TYPE text/enriched DIGEST 16652d45fe62703e11f614889e58cc21 BODY <64>PHVuZGVybGluZT5IZWxsbyBXb3JsZCE8L3VuZGVybGluZT4NCg0KDQpXZWxjb21lI HRvIGFuIDxdGFsaWM+ZXhhbXBsZTwvaXRhbGljPiB3ZWJwYWdlIHdyaXR0ZW4gaW4gZW5yaWN ZWQgdGV4dC4= 5.6 SIMP Media Type The return format of the SIMP standard can be denoted using the "message/vnd.si.simp" Media Type [3], of which the IANA registration is located at [10], where further information regarding the specifics of SIMP and it's Media Type can be found. 5.7 External Sources [1] - "Hypertext Transfer Protocol -- HTTP/1.1" http://www.rfc-editor.org/rfc/rfc2616.txt [2] - "Key words for use in RFCs to Indicate Requirement Levels" http://www.rfc-editor.org/rfc/rfc2119.txt [3] - "Uniform Resource Identifier (URI): Generic Syntax" http://www.rfc-editor.org/rfc/rfc3986.txt [4] - "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types" http://www.rfc-editor.org/rfc/rfc2046.txt [5] - "The MD5 Message-Digest Algorithm" http://www.rfc-editor.org/rfc/rfc1321.txt [6] - "The Base16, Base32, and Base64 Data Encodings" http://www.rfc-editor.org/rfc/rfc3548.txt [7] - "Returning Values from Forms: multipart/form-data" http://www.rfc-editor.org/rfc/rfc2388.txt [8] - "Date and Time on the Internet: Timestamps" http://www.rfc-editor.org/rfc/rfc3339.txt [9] - "OSI Reference Model — The ISO Model of Architecture for Open Systems Interconnection" http://www.comsoc.org/livepubs/50_journals/pdf/RightsManagement_eid=136833.pdf (PDF) [10] - "'message/vnd.si.simp' Media Type Registration" http://www.iana.org/assignments/media-types/message/vnd.si.simp 5.8 Authors Nicholas Parks Young Jordan Geear Please send any comments to admin@shadyindustries.com, prefixing the email subject with #SSD2