This RFC defines the content encoding scheme for a proposed standard protocol for transporting static odor descriptors (SODs) and dynamic odor descriptors (DODs) between clients and servers.
Although this RFC assumes that OTP will be used over a TCP/IP network, there is nothing inherent in its specification that would prevent it from being used on other types of networks.
1. STATUS OF THIS MEMO
This RFC specifies a proposed standard for the Internet community. Since this topic is new to the Internet community, discussions and suggestions are specifically requested.
Please send comments to:
Evan Coyne Maloney
Pencom Web Works
40 Fulton Street
New York, NY 10038
emaloney@pencom.com
Distribution of this memo is unlimited.
2. INTRODUCTION
Increasingly, the Internet is being used to simulate the physical world. Various products that support audio, video, and 3D environments are attempts to stimulate one's senses through technology. As these technologies improve, it will become increasingly difficult to distinguish between senses that are stimulated through artificial means and those that are stimulated through real-world experiences.
It is unfortunate that most media coverage of the artificial stimulation of senses is currently limited to the realm of the visual and the auditory; we feel that for a convincing re-creation of real-world experience, each sense must be stimulated equally.
Although much important work is being done in applying technology to the stimulation of the senses of taste and touch, this paper will focus solely on the sense of smell, solely for the selfish reason that it happens to be the area of expertise of the author and contributors. (It may be interesting to the reader that the genesis of this project was the author's frustration at not smelling the "new car smell" at a popular car manufacturer's web site.)
This RFC outlines a core set of techniques that need to be supported to transport both static and dynamic smells over a network in a way that is both cross-platform and odor output device (OOD) independent.
3. ARCHITECTURE
OTP uses a client-server architecture, whereby one software program initiates a session by sending a request to another software program that processes the request and returns a response.
The software program sending the request is called the "client", and the software program handling the request and returning the response is called the "server". The client and the server may (and will usually) reside on separate machines. Further, software programs may be written that will act as both client and server in different situations, thereby creating a "peer-to-peer" architecture.
During a single transaction, however, the client and the server will be clearly defined.
4. ISSUES
When attempting to design a transport mechanism that will work in a cross-platform environment with a variety of output devices, two issues need to be addressed before any work can progress.
First, the issue of byte ordering needs to be settled. Due to convention, we have adopted the same byte ordering used by TCP/IP networks (and by certain processors, such as the Motorola 68000-line and the PowerPC-line). So as to easily develop cross-platform code, we strongly recommend using the byte-ordering utility functions provided with BSD-compliant packages.
Second, the issue of handling the differing capabilities of a diverse line of output devices needs to be addressed. We have developed a scheme that will allow high-end OODs to utilize their full functionality while maintaining compatibility with low-end OODs.
5. OVERVIEW OF ENCODING SCHEMES
The encoding scheme used for static smells--smells that don't change during their outputting--is called the "Absolute Smell Encoding Scheme", or ASES (pronounced "asses"), and is used to send static odor descriptors to an OTP client.
The encoding scheme used for dynamic smells--smells that can (but are not required to) change during their outputting--is called the "Relative Smell Encoding Scheme", or RSES (pronounced "arses"), and is used to send dynamic odor descriptors to an OTP client.
RSES is a modification of ASES that allows for very fast real-time changes in smell output (smell streaming).
6. ABSOLUTE SMELL ENCODING SCHEME (ASES)
Various OODs have varying capabilities. Primarily, these capabilities differ only in terms of the range of possible odors emitted by the output device. This range of possible odor, known as the device's "smell spectrum", is generally specified internally using numbers that indicate the portion of each odor component that the device is capable of emitting. Often, the numbers used to pinpoint a particular odor on the smell spectrum of a given device are not compatible with those used by another device, and even if they are, there is no guarantee that one device is capable of emitting as many smells as another.
Most devices available today are capable of emitting only 255 smells (256, if you consider "lack of smell" to be a smell itself). These devices are "8-bit smell" devices. New devices are beginning to emerge that support 16-bit smell, capable of outputting 65,535 smells. We settled on using 32-bit encoding scheme, since we expect that--much like color monitors--the maximum bit depth will hit a ceiling at 32-bits. (Will there really be a need for reproducing more than 4,294,967,296 smells? Scientific evidence shows that the human nose can't distingish any resolution higher than that.)
Our encoding scheme groups together similar smells in a tree structure, so that the tree is traversed by each successive bit in a 32-bit number called a smell descriptor number (SDN). Items that lie further down on the tree are increasingly subtle variations on the smells that lie above them. Starting from the root of the tree, a bit value of 0 means traverse the tree's left branch, and a bit value of 1 means traverse the tree's right branch. The least significant bit of the SDN represents the branch to traverse directly under the root.
For example, consider the following imaginary smell tree:
beer
_____________|_____________
| |
ale stout
________|________ ________|________
| | | |
Nevada Pale Ale Geary's Murphy's Guinness
[Figure 1. Tree Example]
Assuming the tree segment in Figure 1 represents the entire smell tree, the smell "beer" represents the root. The tree will always be traversed if the SDN is not 0 (zero). Zero is reserved and is used to indicate the absence of ARTIFICIAL--not real--smell.
(Do not attempt to send SDNs of zero to output devices hoping to remove natural smells; if someone in the cubicle next to you had ten crocks of French Onion Soup for dinner last night, there's not much an OOD can do about it other can cover it up.)
Back to the example. In order to indicate the smell of Guinness in our example above, the SDN would be 11 (in binary). To indicate the smell of Geary's, the SDN would be 01 (in binary).
Now, let's discuss how SDNs can be used approximate smells that the device can't output. Assume that the imaginary OOD we're using is only capable of 1-bit smell. It can only output the smell of ale or stout. That would be fine, since OTP will recognize that the OOD can't handle the additional information. OTP will output smells according to the following method:
Let's say OTP is asked to output the smell of Guinness to a 1-bit OOD. OTP is passed an SDN of 11 (in binary). Since our device is 1 bit, it masks off the most significant bit, and uses the resulting number 1 (in binary), which it uses traverse the tree, outputting a smell of stout, which is fine, because it's close enough to Guinness.
ASES allows for multiple SDNs to be sent in response to one request. This is how smell intensity is managed. More intense smells will have repeated SDNs in response to the request. The more SDNs that are sent, the more intense the smell. This, incidentally, is also how smell dithering can work, since the multiple SDNs sent by the server can be of different values, creating composite smells.
One final note on the smell tree: the left-most branch on the bottom-most portion of the tree will always be used to indicate the lack of smell, since it maps into an SDN of 0. So, the left-most branch on the bottom-most portion of the tree will always look like:
...
|
"smell x"
________|________
| |
--no smell-- "smell x"
[Figure 2. Accouting for an SDN of 0]
The repeated entry for "smell x" on the right-hand side of the tree forces the SDN to contain a most-significant bit of 1, thereby ensuring that no actual smell maps into an SDN of 0.
7. RELATIVE SMELL ENCODING SCHEME (RSES)
The Relative Smell Encoding Scheme is a variation on the Absolute Smell Encoding Scheme that allows real-time streaming of smells. It works by first taking a "base smell" and then notifying the client of any changes in that base smell.
The base smell is a standard SDN as discussed in the section above. Changes are made to that smell by sending the client a series of 2-bit codes (smell modifiers, or SMODs) that modify the current smell.
The SMODs are constructed so that the most-significant bit determines whether the current smell will be modified by traversing the tree up or down, and the least-significant bit determines whether the current smell will be modified by traversing the tree left or right.
If the most-significant bit is 0, the current smell is being changed to the smell that lies directly above it in the tree, and the least-significant bit can be ignored. If the most-significant bit is 1, the current smell is being changed to one of the two smells that lie directly below the current smell on the tree, in which case the least-significant bit is evaluated as a standard bit in the SDN. (In other words, the least-significant is evaluated such that a bit value of 0 means traverse the tree's left branch, and a bit value of 1 means traverse the tree's right branch.)
RSES allows for an unlimited series of SMODs, so the OTP session can be of indeterminate length. Further, it is possible for large lengths of time to pass between SMODs are sent, since a smell may not need to change for a while. This is perfectly acceptable under OTP.
Note that there are cases--such as data corruption--when a request may be made to traverse below the 32-bit depth of the OTP specification, or above the root of the tree. If this happens, synchronization cannot be maintained, so the OTP connection will be reset and a new RSES session will be started. Due to the efficiency of RSES and the lingering property of smells, the user will not notice that anything has gone wrong in this case.
8. CONCLUSION
Each sense has an integral role in our interaction with the physical world. As the Internet is increasingly used to simulate the physical world, it must become better equipped to accurately stimulate all of our senses. OTP is a huge step in this direction, and ASES/RSES will enable us to integrate smell in a cross-platform, device-independent way. We hope that ASES and RSES can help the world smell a whole lot better!