Search

RETS Change Proposal 2: Compression Negotiation
Author: Bruce Toback
Organization:
Telephone:
Address:
Email:
Status: Proposal
Date: 12/29/2001
Proposal Version: 1.0
1. Synopsis
RETS 1.0 does not provide a standard method for client and server to negotiate data compression for query responses. This proposal suggests and standardizes the use of the HTTP Accept-Encoding and Transfer-Encoding headers so that a client and server can negotiate a compression method.
2. Rationale
There is currently no standard method within RETS for a client and server to negotiate a compression method. Since the response to a RETS query can be very large, this represents a deficiency in the current specification. Compression would be even more important if the a LOCAL-XML return type is added to the specification.

By using the HTTP Accept-Encoding header, a client can indicate its readiness to accept a compressed response in an HTTP-compliant way, and the server can similarly use the standard Content-Encoding header to indicate that the response is compressed, and by what method. This preserves normal HTTP processing at both ends.

3. Proposal
3.1 Specification Changes

An Accept-Encoding header following RFC 2616 will be added to Section 3.5 of the RETS protocol specification, describing the current set of optional request headers:

    Accept-Encoding: encoding [,encoding]

where encoding is the MIME type of the encoded data, for example, application/gzip. A client desiring a compressed return SHOULD request (and support) at least application/bzip.

A corresponding Content-Encoding optional response header will be added to Section 3.8 of the specification:

    Content-Encoding: encoding

where encoding is the MIME type of the encoded data. A RETS-compliant server intending to support compression SHOULD support at least application/bzip.

The specification does not require either the client or the server to support compression. The server is permitted to ignore the client's Accept-Encoding header and supply the response unencoded.

3.2 Compression Methods

As noted above, RETS endpoints intending to support compression SHOULD accept and/or generate bzip encoding. bzip is similar to the popular gzip compression method, but has a less restrictive license than the GNU gzip library. (A Java implementation of bzip is also available under the LGPL.) Clients and servers are, of course, free to use any other encoding methods.

4. Development Impact
Because the changes described in this proposal are optional, there is no forced development impact. A client or server writer wishing to implement this proposal will need to integrate the bzip library or a suitable substitute; this will not be difficult except where no library can be found for the development platform. In addition, both client and server will need to be changed to emit and process the new headers. This is generally minor.
5. Compatibility
This proposal relies only on optional HTTP/1.1 header semantics, and servers are permitted to ignore the client's request for compression. Thus, there are no compatibility issues: if both client and server implement this extension, then server responses may be compressed. If either does not implement the extension, responses will be sent uncompressed, as now.
6. Proof/Need of Concept Examples
None.