This document provides a technical synopsis of the giftpool protocol, which is the protocol used to conduct giftfile system transactions. The protocol is presented through an examination of what is actually going over the wire. We'll see a good sample of situations, including server method discovery, donation from a new user, giftfile allocation, and producer remittance.
The giftpool protocol is implemented in HTTP + XML using the REST architecture style. Because all state is explicitly contained in the protocol messages, and simple HTTP is used to the fullest, this synopsis should be relatively easy to follow.
Design notes are shown in italics.
This is a work in progress. Please send feedback to info@giftfile.org.
To begin, we assume the client agent possesses the URI of the giftpool which the user wants to use. In this case it's http://example.net/. First the agent will check for an interface it understands, and discover the methods within that interface. Here is the HTTP request:
GET / HTTP/1.1 Host: example.net Accept: application/xml
For those not familiar with the "Accept" header, it is used for HTTP content negotiation. For a given URL, the server may have multiple representations of the same resource. For example, if you visit the URL will your browser, you might get the HTML representation. In the request shown above, we are asking for the XML representation, which is intended for automated use by giftpool clients.
Here is the server's response to our request:
HTTP/1.1 200 OK
Etag: W/"3"
Content-Type: application/xml
<interfaces xmlns="http://giftfile.org/2003/01/giftpool#">
<interface>
<info>http://example.net/1/info</info>
<public_record_search>http://example.net/1/</public_record_search>
<private_record_search>http://example.net/1/private/</private_record_search>
<donation_request>http://example.net/1/donation_request</donation_request>
<allocation_request>http://example.net/1/allocation_request</allocation_request>
<remittance_request>http://example.net/1/remittance_request</remittance_request>
<record_deletion_request>http://example.net/1/record_deletion_request</record_deletion_request>
<admin>...</admin>
</interface>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</interfaces>
In its reply, the giftpool server enumerates the available interfaces. Each interface might support a different version of the giftpool protocol, enabling graceful upgrades of the system. However, this server has only a single interface. Within the interface are links to available "method" resources, such as the URL to use when making an allocation.
Note that for brevity, some details of the communication are being omitted, such as the signature element and certain HTTP headers (Content-Length, etc.).
The response XML is signed using the XML Signature standard. Instead of relying on SSL, the giftpool protocol uses cryptographic signatures for authorization. The main reason is that such message-unit authorization, in contrast to SSL's session-unit authorization, allows messages to stand on their own as proof of a transaction.
The giftpool protocol supports only PGP signature types. Since the PGP key infrastructure is decentralized, it is up to the client to employ the web of trust to verify the giftpool's key.
If the client had asked for HTML, the response would have contained links suitable for navigation in any web browser. In cases where the resource expects complicated data to be posted, the links are not very useful for browsing. However, some resources, such as public_record_search, work normally from a browser.
In the future, we may want to employ XLink for all links used in the protocol.
It may seem verbose to use absolute URI's for each item. However, according to REST, URI's must be treated as opaque. For example, the client should not be guessing the location of the giftpool root resource (http://example.net/) based on the donation request resource (http://example.net/1/donation_request). We could consider using an absolute URI for only the giftpool resource link, and then making the other links relative to that.
Let's make use of one the methods we discovered, info, to find out more about the giftpool:
GET /1/info HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 200 OK
Etag: W/"173"
Content-Type: application/xml
<giftpool_record xmlns="http://giftfile.org/2003/01/giftpool#">
<uri>http://example.net/</uri>
<id>44f91abd6dc120cf8a33e11459a6d055e23478ce</id>
<name>Giftfile Project Test Giftpool</name>
<location>Greenfield Center, NY, USA</location>
<operating_since>2004-05-12Z</operating_since>
<donation_payee>EGE, Inc.</donation_payee>
<donation_address>TEST!! Giftpool Donations
EGE, Inc.
PO BOX 392
GREENFIELD CENTER NY 12833-0392
USA</donation_address>
<issue_uri>mailto:test-giftpool-issues@giftfile.org</issue_uri>
<user_keyserver>http://example.net:11372/</user_keyserver>
<currency_unit>USD</currency_unit>
<currency_precision>2</currency_precision>
<donation_friction>0.25</donation_friction>
<remittance_friction>1.00</remittance_friction>
<minimum_allocation>0.01</minimum_allocation>
<producer_allocation_delay>86400</producer_allocation_delay>
<producer_minimum_income>1.00</producer_minimum_income>
<request_max_age>259200</request_max_age>
<users_count>20</users_count>
<producers_count>9</producers_count>
<giftfiles_count>29</giftfiles_count>
<donations_count>30</donations_count>
<donations_amount>1660.00</donations_amount>
<grants_amount>484.73</grants_amount>
<holdings_amount>1175.27</holdings_amount>
<allocatable_holdings_amount>1167.77</allocatable_holdings_amount>
<efficiency>1.00</efficiency>
<modified>2004-05-13T17:12:20Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</giftpool_record>
Note that, in the uri element, the message includes a link back to the root giftpool resource. This is done for most messages returned by the server, so that they have meaning independent of the current context—a REST principle. Think of this as you would a web page containing an absolute link to its own location: you have the ability to refer to the original even when viewing the page from a mirror site.
Another item to point out is the id element. In most cases, the giftpool protocol uses forty digit hexadecimal numbers as identifiers. In the case of a giftpool, the ID is the same as the giftpool's PGP fingerprint. For the remainder of this document, all ID's will be truncated after the first six digits (e.g., "44f91a...").
This is a good place to bring up another benefit of REST: it is very friendly to caching. The request may have been serviced by a gateway on the server end, a proxy on the client end, or anything in the middle. This contrasts with remote procedure calls, which cannot be cached because the method name and arguments exist within the HTTP request entity (body) rather than the URI. The use of individually signed messages rather than SSL, mentioned previously, also allows caching to work.
The client agent we are watching is acting on behalf of Donald, who is new to the giftfile system and would like to make his first donation. First he must let the giftpool know about his intention to make a donation. His client does an HTTP POST to the donation_request resource of the giftpool:
POST /1/donation_request HTTP/1.1
Host: example.net
Content-Type: application/xml
<donation_request xmlns="http://giftfile.org/2003/01/giftpool#">
<user_id>a98a67...</user_id>
<issued>2004-05-13T17:12:42Z</issued>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</donation_request>
HTTP/1.1 201 Created
Location: http://example.net/1/private/donations/019d5c...
Here we see that requests to the server are also signed, this time by the user's PGP key rather than the giftpool's. Like giftpool ID's, user ID's are the PGP fingerprint of the user.
The server responded with the URI of a newly created donation record. The donation record represents the transaction of Donald sending money to the giftpool.
One of the data items in the request is issued, which is the time that Donald told his client that he'd like to make the transaction. This time may be different from when the request was sent to the giftpool due to circumstances such as the client or the server being offline. As we'll see, the server holds on to such state data and in turn makes it available to clients. This allows state synchronization with client instances other than the one which issued the request.
It should be noted that a donation request is the only case where the giftpool server will allow a stranger to create new resources. In this case, it will protect itself from attacks by automatically limiting the number of such requests coming from the same IP address over a given amount of time, possibly contacting a giftpool administrator when such an event occurs.
Now Donald's agent grabs the donation record:
GET /1/private/donations/019d5c... HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 200 OK
Etag: W/"1"
Content-Type: application/xml
<donation_record xmlns="http://giftfile.org/2003/01/giftpool#">
<giftpool>http://example.net/</giftpool>
<uri>http://example.net/1/private/donations/019d5c...</uri>
<user>http://example.net/1/private/users/a98a67...</user>
<payment_id>94b24b0d</payment_id>
<status>1.2 Payment Not Received</status>
<donation_amount/>
<privilege_amount/>
<payer_name/>
<payment_type/>
<check_number/>
<issued>2004-05-13T17:12:42Z</issued>
<created>2004-05-13T17:12:46Z</created>
<modified>2004-05-13T17:12:46Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</donation_record>
Since Donald is new to this giftpool, in addition to the donation record, a user record was also created for him. This resource is given by the user item, and Donald's client will make note of it for later use.
Besides the user URI, an interesting item in this record is the payment ID. Donald must mark his payment with this ID—for example, by writing it on the comment line of his check—so that the giftpool can match the payment to this donation record.
Another significant item in the record is the donation status. Similar to HTTP, status is represented by a code number and human-readable message. The code space is divided into classes so that, should a client not recognize a specific code, it can still operate according to the general meaning of the class. In this case the class is "1.x", which means that the transaction is still being processed.
Now let's follow the link to Donald's user record:
GET /1/private/users/a98a67... HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 200 OK
Etag: W/"12"
Content-Type: application/xml
<user_record xmlns="http://giftfile.org/2003/01/giftpool#">
<giftpool>http://example.net/</giftpool>
<uri>http://example.net/1/private/users/a98a67...</uri>
<id>a98a67...</id>
<status>1.1 New User</status>
<total_donation_amount>0.00</total_donation_amount>
<total_allocation_amount>0.00</total_allocation_amount>
<total_income_amount>0.00</total_income_amount>
<total_remittance_amount>0.00</total_remittance_amount>
<privilege_by_donation>0.00</privilege_by_donation>
<privilege_by_income>0.00</privilege_by_income>
<delayed_income_amount>0.00</delayed_income_amount>
<allocation_privilege>0.00</allocation_privilege>
<remittance_privilege>0.00</remittance_privilege>
<pending_allocation_amount>0.00</pending_allocation_amount>
<donations>
<li>http://example.net/1/private/donations/019d5c...</li>
</donations>
<allocations/>
<giftfiles/>
<remittances/>
<created>2004-05-12T04:04:32Z</created>
<modified>2004-05-13T17:12:46Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</user_record>
So it's clear he is a fresh user, with all balances in his account at zero. His status is "New User", which means he does not yet have normal user privileges. Those will be granted to him once his first donation payment is settled.
Included in his record is a list of links to his donations. In this way, if Donald should run some other client software, it could build a database of all pending and completed transactions given just his user URI.
What is not shown here is that Donald's user record is encrypted. The server encrypts it to Donald's PGP key, using the XML Encryption standard, so that only he may view it. Many record types, such as user records, have both a public and private version. Public records, which omit details which may be sensitive, are not encrypted. So how do we access Donald's public record? The server has several query methods which are used to access both public and private versions of user and giftfile records. Let's try locating Donald's public record. We append a "?user=<user_id>" query to the public record search URL published in the giftpool interface:
GET /1/?user=a98a67... HTTP/1.1 Host: example.net Accept: application/xml HTTP/1.1 302 Found Location: http://example.net/1/users/a98a67...
Note that the resulting URL is different than that of Donald's private user record.
After sending his check to the giftpool, Donald will have to wait several days while it is delivered and processed. During this time, it's the job of his agent to periodically poll the donation record to see if it has been updated with new status information. Records on the server may be efficiently polled through use of HTTP's conditional GET operations. Here the client does this, using the HTTP entity tag of the previous response:
GET /1/private/donations/019d5c... HTTP/1.1 Host: example.net Accept: application/xml If-None-Match: W/"1" HTTP/1.1 304 Not Modified Etag: W/"1"
Despite the efficiency of this operation, the server might not allow Donald's client to poll too frequently. Let's look at what happens when a rate limit is exceeded:
GET /1/private/donations/019d5c... HTTP/1.1 Host: example.net Accept: application/xml If-None-Match: W/"1" HTTP/1.1 503 Service Unavailable Retry-After: 7200
The giftpool server refused to hand over the record, giving a hint to the client: retry after 2 hours (7,200 seconds).
Fast forwarding to one week later, the donation record has finally be updated, as is reflected in this poll by the agent:
GET /1/private/donations/019d5c... HTTP/1.1
Host: example.net
Accept: application/xml
If-None-Match: W/"1"
HTTP/1.1 200 OK
Etag: W/"3"
Content-Type: application/xml
<donation_record xmlns="http://giftfile.org/2003/01/giftpool#">
<giftpool>http://example.net/</giftpool>
<uri>http://example.net/1/private/donations/019d5c...</uri>
<user>http://example.net/1/private/users/a98a67...</user>
<payment_id>94b24b0d</payment_id>
<status>2.0 OK</status>
<donation_amount>25.00</donation_amount>
<privilege_amount>24.75</privilege_amount>
<payer_name>Donald D. Donaldson</payer_name>
<payment_type>check</payment_type>
<check_number>101</check_number>
<issued>2004-05-13T17:12:42Z</issued>
<created>2004-05-13T17:12:46Z</created>
<modified>2004-05-13T17:12:47Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</donation_record>
According to the record, Donald's donation has been received by the giftpool and his check has cleared. Shown in the record are the amount of his check, and how much allocation privilege he was awarded.
So now let's examine his user record again:
GET /1/private/users/a98a67... HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 200 OK
Etag: W/"13"
Content-Type: application/xml
<user_record xmlns="http://giftfile.org/2003/01/giftpool#">
<giftpool>http://example.net/</giftpool>
<uri>http://example.net/1/private/users/a98a67...</uri>
<id>a98a67...</id>
<status>2.0 OK</status>
<total_donation_amount>25.00</total_donation_amount>
<total_allocation_amount>0.00</total_allocation_amount>
<total_income_amount>0.00</total_income_amount>
<total_remittance_amount>0.00</total_remittance_amount>
<privilege_by_donation>24.75</privilege_by_donation>
<privilege_by_income>0.00</privilege_by_income>
<delayed_income_amount>0.00</delayed_income_amount>
<allocation_privilege>24.75</allocation_privilege>
<remittance_privilege>0.00</remittance_privilege>
<pending_allocation_amount>0.00</pending_allocation_amount>
<donations>
<li>http://example.net/1/private/donations/019d5c...</li>
</donations>
<allocations/>
<giftfiles/>
<remittances/>
<created>2004-05-12T04:04:32Z</created>
<modified>2004-05-13T17:12:47Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</user_record>
Donald's status as a user has changed to "OK", and he has privileges to allocate $24.75. Note that there is still a link to the donation record, even though the donation has been completed. As a convenience to clients, the server holds such retired records, although after some time it may purge them automatically. In the case of donation records, the client has permission to delete the record. The concept is similar to a POP mailbox, where the decision to leave messages on the server or not is left to the client.
Donald's client happens to be configured to delete records as soon as a transaction completes:
POST /1/record_deletion_request HTTP/1.1
Host: example.net
Content-Type: application/xml
<record_deletion_request xmlns="http://giftfile.org/2003/01/giftpool#">
<user_id>a98a67...</user_id>
<records>
<li>http://example.net/1/private/donations/019d5c...</li>
</records>
<issued>2004-05-13T17:12:49Z</issued>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</record_deletion_request>
HTTP/1.1 200 OK
The server indicates that the deletion was successful. Donald's user record will no longer contain a link to the donation record.
Now that Donald has allocation privileges burning a hole in his pocket, he decides to spend some on a few giftfiles he's been using. Giftfiles always have an associated certificate, which will be required by the agent to make an allocation. Since allocations are the most frequent giftpool transactions, more than one may be combined into a single request. The agent posts to the allocation_request resource:
POST /1/allocation_request HTTP/1.1
Host: example.net
Content-Type: application/xml
<allocation_request xmlns="http://giftfile.org/2003/01/giftpool#">
<user_id>a98a67...</user_id>
<allocations>
<li>
<giftfile_id>9ba346...</giftfile_id>
<allocation_amount>1.50</allocation_amount>
</li>
<li>
<giftfile_id>44fa29...</giftfile_id>
<allocation_amount>0.25</allocation_amount>
</li>
</allocations>
<issued>2004-05-13T17:12:45Z</issued>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</allocation_request>
HTTP/1.1 201 Created
Location: http://example.net/1/private/allocations/113ecc...
In the allocation request, each giftfile is referenced by an ID which was extracted from the giftfile's certificate. The server responds with the URI of the allocation record.
The giftpool protocol doesn't specify a maximum number of allocations per request or maximum message size. These limitations depend on the server implementation. Should a request exceed some limit, the server response would have been:
HTTP/1.1 413 Request Entity Too Large
Now let's look at the newly created allocation record:
GET /1/private/allocations/113ecc... HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 200 OK
Etag: W/"3"
Content-Type: application/xml
<allocation_record xmlns="http://giftfile.org/2003/01/giftpool#">
<giftpool>http://example.net/</giftpool>
<uri>http://example.net/1/private/allocations/113ecc...</uri>
<user>http://example.net/1/private/users/a98a67...</user>
<allocations>
<li>
<giftfile_id>9ba346...</giftfile_id>
<giftfile_record>http://example.net/1/giftfiles/9ba346...</giftfile_record>
<amount>1.50</amount>
<status>2.0 OK</status>
</li>
<li>
<giftfile_id>44fa29...</giftfile_id>
<amount>0.25</amount>
<status>4.5 Invalid Resource</status>
</li>
</allocations>
<total_requested_amount>1.75</total_requested_amount>
<total_successful_amount>1.50</total_successful_amount>
<status>2.0 OK</status>
<issued>2004-05-13T17:12:45Z</issued>
<created>2004-05-13T17:12:49Z</created>
<modified>2004-05-13T17:12:49Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</allocation_record>
Allocation transactions are somewhat complicated, and this is reflected by the record above. Besides there being a status for the whole transaction, each individual allocation also has a status, allowing it to succeed or fail independently of the others. The allocations are listed in the same order as in the original allocation request. If there is a problem with one of the allocations, the agent will be able to correlate this to the original request and take appropriate action. In this example, although the first allocation succeeded, the second failed with "Invalid Resource". This is a normal, though rare, situation where the giftpool has not yet encountered the referenced giftfile. The agent will have to resend that part of the allocation, this time supplying the full giftfile certificate.
For each allocation that succeeds, its entry in the allocation record is expanded to include a link to the associated giftfile record.
We should expect to see a link in Donald's user record to this allocation record. His client may delete the record should it no longer be required. Things work basically as they did for the donation.
The giftfile that Donald successfully allocated to was published by a certain user named Richard. Let's switch our perspective now to Richard's agent. Working from the giftfile's ID, it will locate and then examine that giftfile's private record:
GET /1/private?giftfile=9ba346... HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 302 Found
Location: http://example.net/1/private/giftfiles/9ba346...
GET /1/private/giftfiles/9ba346... HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 200 OK
Etag: W/"2"
Content-Type: application/xml
<giftfile_record xmlns="http://giftfile.org/2003/01/giftpool#">
<giftpool>http://example.net/</giftpool>
<uri>http://example.net/1/private/giftfiles/9ba346...</uri>
<id>9ba346...</id>
<user>http://example.net/1/private/users/6cc506...</user>
<allocations_count>1</allocations_count>
<allocations_amount>8.91</allocations_amount>
<certificate>...</certificate>
<created>2004-05-13T17:12:49Z</created>
<modified>2004-05-13T17:12:49Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</giftfile_record>
Remember that private records such as this are encrypted to the PGP key of the owner, in this case Richard.
Each giftfile record contains the complete certificate, not shown here, along with various accounting data.
Let's follow the user link to view Richard's user record:
GET /1/private/users/6cc506... HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 200 OK
Etag: W/"14"
Content-Type: application/xml
<user_record xmlns="http://giftfile.org/2003/01/giftpool#">
<giftpool>http://example.net/</giftpool>
<uri>http://example.net/1/private/users/6cc506...</uri>
<id>6cc506...</id>
<status>2.0 OK</status>
<total_donation_amount>0.00</total_donation_amount>
<total_allocation_amount>0.00</total_allocation_amount>
<total_income_amount>54.30</total_income_amount>
<total_remittance_amount>24.39</total_remittance_amount>
<privilege_by_donation>0.00</privilege_by_donation>
<privilege_by_income>26.91</privilege_by_income>
<delayed_income_amount>1.50</delayed_income_amount>
<allocation_privilege>25.91</allocation_privilege>
<remittance_privilege>25.91</remittance_privilege>
<pending_allocation_amount>0.00</pending_allocation_amount>
<donations/>
<allocations/>
<giftfiles>
<li>http://example.net/1/private/giftfiles/494b45...</li>
<li>http://example.net/1/private/giftfiles/895f46...</li>
<li>http://example.net/1/private/giftfiles/9ba346...</li>
<li>http://example.net/1/private/giftfiles/cd27f9...</li>
</giftfiles>
<remittances/>
<created>2004-05-12T00:58:08Z</created>
<modified>2004-05-13T17:12:49Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</user_record>
We can see that all of Richard's giftfiles are listed, in the same manner done for donations and allocations.
Income accounting is somewhat complicated, reflecting a few rules designed to protect against denial of service attacks: a delay exists between when a producer's giftfile receives an allocation and when he can in turn allocate that money to another giftfile; and a producer may not, by an allocation, deplete his producer balance beyond the remittance friction.
The only giftpool transaction we haven't seen yet is a remittance, where a producer uses his privilege gained by income to request a cash grant from the giftpool. Fortunately, Richard has decided to do just that. His agent posts to the remittance_request resource:
POST /1/remittance_request HTTP/1.1
Host: example.net
Content-Type: application/xml
<remittance_request xmlns="http://giftfile.org/2003/01/giftpool#">
<user_id>6cc506...</user_id>
<remittance_amount>25.91</remittance_amount>
<payee_name>Test Payee</payee_name>
<delivery_address>Richard R. Richardson
PO BOX 555
AUSTIN TX 55555</delivery_address>
<issued>2004-05-13T17:12:47Z</issued>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</remittance_request>
HTTP/1.1 201 Created
Location: http://example.net/1/private/remittances/470f52...
Content-Type: text/plain; charset=ISO-8859-1
By the way, what would happen if Donald's agent sent the same remittance request a second time? The request would be successful, yielding exactly the same server response. In other words, the reply would point to the same remittance record. This is one aspect of a concept called reliable messaging, which has been designed into the giftfile protocol. If a client is not sure if the server received a request, such as in the situation of a crash, it can and should resend the request. The server will silently ignore any requests which it has already seen.
Richard's agent next examines the new remittance record:
GET /1/private/remittances/470f52... HTTP/1.1
Host: example.net
Accept: application/xml
HTTP/1.1 200 OK
Etag: W/"1"
Content-Type: application/xml
<remittance_record xmlns="http://giftfile.org/2003/01/giftpool#">
<giftpool>http://example.net/</giftpool>
<uri>http://example.net/1/private/remittances/470f52...</uri>
<user>http://example.net/1/private/users/6cc506...</user>
<privilege_amount>26.91</privilege_amount>
<remittance_amount>25.91</remittance_amount>
<payee_name>Richard R. Richardson</payee_name>
<delivery_address>Richard R. Richardson
PO BOX 555
AUSTIN TX 55555</delivery_address>
<check_number/>
<check_date>2004-05-13Z</check_date>
<status>1.0 Processing</status>
<issued>2004-05-13T17:12:47Z</issued>
<created>2004-05-13T17:12:50Z</created>
<modified>2004-05-13T17:12:50Z</modified>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>
</remittance_record>
As with donation transactions, the status of the remittance record will change over the next few days. When the check is sent out by the giftpool, the status will become to "Remittance Issued". After Richard cashes the check, it will change to "OK", completing the transaction.
$LastChangedDate: 2007-10-03 21:49:24 -0400 (Wed, 03 Oct 2007) $