— The notion of voice ropes is separate from the garbage collection of unwanted tunes. A voice rope package provides clients the ability to manipulate voice in familiar and useful ways. Garbage collection is necessary to free up the space occupied by unneeded recorded voice; some way of expressing interests in voice is required in order to determine what is "garbage". Thus, perhaps VoiceRopes and VoiceInterest should be different interfaces.

— What is the intended functionality available through the InterVoice interface? How does it relate to VoiceRopes and VoiceInterest? Certainly we need operations for recording and playing voice ropes; these are independent from the other voice rope operations.

— Voice ropes must have unique identifiers. Should these be assigned by the voice system or chosen by clients? My feeling is that the system should generate unique identifiers (this was the assumption in the 12-10-84 voice rope proposal); client applications making use of voice ropes should be free to build their own voice rope name spaces by registering name attributes along with their interests. Accessing voice ropes through client-defined names would involve a lookup in the interest database to get the VoiceRopeID followed by the usual voice rope operations.

— Does every voice rope operation produce a new voice rope on the server? A sequence of operations may be needed to generate a new voice rope that the client is interested in, e.g. building a new rope that is the concatenation of substrings of two existing voice ropes. The intermediary operations produce voice ropes that are only temporarily needed. If these temporary ropes are stored in the server's database, then more work is generated for the garbage collector. Perhaps, some notion of voice ropes that are managed solely on the client's machine is needed. These temporary ropes may be added to the server's database when the client expresses an interest in retaining the voice rope.

— How are voice ropes represented? There are two choices: a voice rope can either be a sequence of intervals of other voice ropes or can be represented completely in terms of tune intervals. The first choice makes editing operations faster, while the second improves the cost of retrieving, i.e. playing, voice ropes. In other words, at some point in time, the base structure of a voice rope must be retrieved from the database; the first choice builds up a hierarchy of voice ropes that must be traversed during playback, while the second choice flattens the hierarchy by combining the basic pieces whenever a new voice rope is created from existing voice ropes. In my opinion, representing voice ropes strictly as a sequence of tune intervals is preferable (this approach was also advocated in the 12-10-84 voice rope proposal).

— The analogy between Ropes and VoiceRopes, as I understand it, is as follows:

— LoganBerry can be used to manage both the voice rope and interest databases. The basic editing operations do not require interactions with Bluejay, but operations such as Fetch or DescribeRope are almost entirely handled by Bluejay. Sequences of tune intervals need to be marshaled into ropes to store them in a LoganBerry database. We could design our own marshaled format. Or perhaps we should use Howard Sturgis' or Bob Hagmann's marshalling package to do this.

— Issues of security need to be worked out. Who is responsible for managing the encryption keys for tunes? Storing them in the voice rope database does not seem to be the right solution since a voice rope can be composed from many tunes and a given tune can be used in many voice ropes. Also, do we need to control access to voice ropes? If so, some sort of access control lists must be stored in the database.