Internet-Draft DotGNU Project Expires: June 2, 2005 December 3, 2004 QQP - Quick Queues Protocol Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, the author represents that he is not aware of any applicable patent or other IPR claims, and any of which he becomes aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 1, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract QQP is a protocol which describes how a Sender transmits some SXDF data to a Receiver, and what the Receiver will do with the data. QQP plays the role of transport protocol for the QRPC webservice protocol, similar to how XML-RPC and SOAP often use HTTP as transport protocol. 1. Introduction Over the past few years, "webservices" protocols such as for example SOAP or XML-RPC have started becoming popular. The fundamental idea of "webservices" is to access functionality on another computer by means of standardized multi-purpose protocols and a standardized extensible data format. For example, when using the "webservices" paradigm to specify a message transport system, you don't specify the protocol and data format from scratch like it is done for SMTP in [RFC2821] and [RFC2822]; instead you specify them in terms of a general-purpose data format (often XML) and a general-purpose protocol for transporting data between computers. QQP, the Quick Queues Protocol, is such a general data transport protocol, specifically for data in the SXDF format [SXDF]. Each SXDF resource contains an Element named Action which specifies what the receiver should do with the resource. 2. Data Transport The purposes of the QQP protocol is to transport data, which is required to be in SXDF format, from a Sender to a Receiver, over a TCP or SSL connection, as follows: Sender opens a TCP connection to port 26. Receiver sends a SXDF resource called the "Greeting" which contains values for "ItemLimit", "SessionLimit" and "Capabilities" (see below). Then Sender can either close the connection or send a data item which is a SXDF resource of size not exceeding the SessionLimit value. When this SXDF resource has been received, the Receiver sends a status string. If the Status Code (see below) is 3 or greater, Receiver closes the connection. Otherwise, Sender is free to either close the connection or send another data item. QQP works similarly over SSL connections, except that in that case port 27 is used. 3. The Greeting The Greeting is a SXDF resource which contains values for "ItemLimit", "SessionLimit", "Capabilities" and "ExceptionsTo". ItemLimit MUST be a positive integer value specifying a size limit for data items (which are SXDF resources) that Receiver will accept. The size of a SXDF resource is the value of the datasize field plus the number of digits of the datasize field plus two. Sender SHOULD assume that this is a hard limit which will not change except if the receiving QQP server is manually reconfigured by an administrator. Any attempt to send larger SXDF resources SHOULD therefore fail with a permanent error. SessionLimit MUST be a nonnegative integer value describing the Receiver's current estimate of the total amount of SXDF resources which Receiver is currently able to accept. The Sender MUST NOT send an amount of data exceeding SessionLimit during this TCP connection; however Sender is free to initiate a new TCP connection after the limit has been reached. Receiver SHOULD, to its best knowledge, be capable of receiving an initial SXDF resource of size up to min(ItemLimit, SessionLimit). After receiving a SXDF resource, returning a Status Code (see below) of 1 or 2 indicates that Receiver SHOULD, to its best knowledge, be capable of receiving another SXDF resource of size min(ItemLimit, SessionLimit-data_so_far), where data_so_far is the sum of sizes of the SXDF resources which have so far been transmitted in the session. Capabilities is an array of strings. For example, if Receiver is capable of processing resources where the Action element contains a qrpc: URL [QRPC], the Capabilities element should contain the string "qrpc". ExceptionsTo SHOULD be a qrpc URL where QRPC Exception resources can be received. If Sender detects wrong behavior of the QRPC server, it SHOULD make an attempt to use this qrpc URL for reporting the error. 4. Required Elements 4.1 Data Element Sender SHOULD ensure that each SXDF resource which it transmits contains a Data element which contains at least an Action Element and a ResourceID element. The Data element MAY contain any number of additional elements. 4.1. Action Element Sender SHOULD ensure that each SXDF resource which it transmits contains an Action element with a value which is a valid URL of a type which receiver has included in the Capabilities array in the Greeting. 4.2. ResourceID Element Sender SHOULD ensure that each SXDF resource which it transmits contains a unique ResourceID Element. For example, Sender MAY use a Universal Unique IDentifier (see [UUID]). 5. Signatures The SXDF resource MAY contain a Signature element holding a digital signature in OpenPGP format, as specified in [RFC 2440]. If present this MUST be a signature of type 0x00 (see section 5.2.1 of [RFC2440]) of the contents of the Data element, excluding the initial "4:data=\n" but including the final "\n". Before signing, the contents of the Data element MUST be canonicalized by removing any and all space characters which follow a newline character but which are not part of a string value. For example, suppose the Data element is as follows: 4:Data=3% 6:Action=28:qrpc://example.com/add_books 10:ResourceID=28:34DH734HF64HF734@example.org 8:Booklist=3@ 5% 5:Title=16:Hardware Hacking 6:Author=19:Kevin Mitnick (Ed.) 4:Year=4:2004 4:ISBN=13:1-932-26683-6 9:Publisher=8:Syngress 5% 5:Title=12:We the Media 6:Author=11:Dan Gillmor 4:Year=4:2004 4:ISBN=13:0-596-00733-7 9:Publisher=8:O'Reilly 5% 5:Title=22:Matrix Decision Making 6:Author=21:Alex Lowy & Phil Hood 4:Year=4:2004 4:ISBN=13:0-787-97292-4 9:Publisher=11:Jossey-Bass Then this is the canonicalized version which will be signed: 3% 6:Action=28:qrpc://example.com/add_books 10:ResourceID=28:34DH734HF64HF734@example.org 8:Booklist=3@ 5% 5:Title=16:Hardware Hacking 6:Author=19:Kevin Mitnick (Ed.) 4:Year=4:2004 4:ISBN=13:1-932-26683-6 9:Publisher=8:Syngress 5% 5:Title=12:We the Media 6:Author=11:Dan Gillmor 4:Year=4:2004 4:ISBN=13:0-596-00733-7 9:Publisher=8:O'Reilly 5% 5:Title=22:Matrix Decision Making 6:Author=21:Alex Lowy & Phil Hood 4:Year=4:2004 4:ISBN=13:0-787-97292-4 9:Publisher=11:Jossey-Bass 6. Status Strings A Status String is a netstring (as specified in [Netstring] which starts with three digits and then a " ". Only the first digit contains standardized status information; the remaining two digits can be freely used by implementations for communicating implementation-specific status information which may be useful for diagnostic and debugging purposes. The possible values of the first digit and corresponding semantics are: 1 - "Redundant". The SXDF resource is being ignored because a SXDF resource with identical ResourceID has been received before. Receiver MAY check for resource duplication and generate this status code in the case that resource duplication has been detected. 2 - "Received alright; next resource please". 3 - "Received alright; closing connection". 4 - "Temporary error; please try again later". 5 - "Permanent error: something is wrong with this SXDF resource". Receiver MAY check for errors such as syntax errors or problems with the content of the Data element; in this case it MAY use this status code and close the connection if an error is detected. Receiver MAY do this also if there is no Signature, a wrong Signature, or a signature which cannot be checked. 6 - "Undefined status: something is wrong, but it isn't known whether this condition is temporary or permanent." 6. Out-Of-Band Error Checking Receiver MAY check for resource duplication and/or for errors in a way which for implementation-related reasons does not allow to generate the "1" or "5" status code during the QQP protocol interaction. In this case Receiver SHOULD report the error by sending a QRPC Exception resource to the ExceptionsTo URL of the data item for which the error has been detected if it has an ExceptionsTo URL; if the data item has no ExceptionsTo URL, Receiver SHOULD NOT generate a QRPC Exception resource. 7. Security Considerations Webservices typically act on untrusted data; they therefore need to be carefully designed and reviewed to prevent security breaches. When webservice requests are transmitted over an untrusted network, firewalls are RECOMMENDED as an additional line of defense. 8. IANA Considerations A request will be made to IANA to operate a registry for the possible string values in the Capabilities list in the greeting, and their meaning. References Normative References [Netstrings] Bernstein, D. J., "Netstrings" [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., Eds., "Uniform Resource Locators", RFC 1738. [SXDF] Bollow, N., "SXDF - Simple Extensible Data Format", work in progress. [QRPC] Bollow, N., "QRPC - Queueable Remote Procedure Calls", work in progress. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., Thayer, R. "OpenPGP Message Format", RFC 2440 Informative References [UUID] International Organization for Standardization: "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)", ISO/IEC 11578:1996. [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821. [RFC2822] Resnick, P., Ed., "Internet message format", RFC 2822. Authors' Address Norbert Bollow Weidlistrasse 18 CH-8624 Gruet Pone: +41 1 972 2059 EMail: nb@bollow.ch Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.