(idea) by Highlander Mon Dec 13 2004 at 17:10:10
RFC 218705161 

Network Working Group                            P. Schaefer
E2 Softlinking Division                               E2 DOG 
Request For Comments:                             08.12.2004

Status of this memo

This RFC describes an experimental protocol for audio transmission to be employed by canines for the transfer of urgent messages. A test of the protocol has been witnessed firsthand by the author. As an Internet-Draft, it awaits approval by IETF IAB.

Intent and Scope

In contrast to defining an unyielding dogma, this RFC focuses on an extensible framework for messaging and basic transmission content. Unlike RFC 1149 and RFC 2549, which has strictly defined routes, this RFC is considering an informally connected network infrastructure, forming a larger network from LANs. While variants of this protocol can easily be simulated on the application layer, the protocol is optimized for acoustic data links.

Why there is a need for such a protocol

Imagine a dog that has been locked up in a car in the summer. It is getting hot, temperature inside the car is rising, the dog is getting dehydrated and will get a stroke. Clearly the dog needs to signal to his owner and best friend that it needs help. However, the owner is out of range for direct audio transmission and visual contact is not available. If the owner hears any dog bark, he surely will remember.

Approach

To signal his distress, the dog will start an audio broadcast, which is picked up by other listening dogs in the proximity. Based on the information contained in the transmission, these other dogs will decide whether to act as repeaters for the transmission. The implementation of the decision algorithm is up to the individual dogs, though we expect a standard to emerge soon, which is left to another RFC.

Terminology

dog
Any node at the center of a local network with the capabilities for listening and broadcasting.
sender
A sender of acoustic messages
recipient
The final intended recipient of the message. The sender MAY specify a non-matching recipient signature for the purpose of a network scan.
repeater
a dog that received a message and decides to repeat it by broadcasting it on its network.

Message blocks

A message is composed of the following blocks:
class
The class of the message. Potential repeaters will use the class to determine whether to repeat the message and the appropriate acoustic level.
recipient signature
A signature that describes the recipient. The signature is computed from audiovisual and olfactory cues.
sender signature
a unique audio signature of the sender
orig-from signature(optional)
The unique audio signature of the initial sender. This SHOULD be modified by distance indicators, when repeated. It is an OPTIONAL field; the repeater MAY omit it if it has determined the message class signals a broadcast.
end of message indicator
extensions to the protocol MAY replace this indicator with additional data indicators.

Message Meta Data

Distance can be measured by implementing a built-in element of signal decay, putting transmission errors to good use. Repeaters SHOULD modify the sender signature when repeating the message. Repeaters MAY modify the recipient signature to reflect additional information available to them.

Repeating decision algorithm, minimum requirements

A candidate repeater SHOULD implement a repeating decision algorithm such that the likelyhood of deciding to act as a repeater increases with the probability that the receiver is closer to the repeater than to the sender. This ensures efficiency of the protocol.

These requirements have been chosen to give the additional benefit of being able to scan for the recipient by increasing the frequency and total volume of transmissions near the recipient.

Security

Since this is a public broadcast protocol, there is no expectation of privacy. Denial Of Service is a serious concern, and is mitigated by delegating the task of deciding which message to repeat to the candidate repeaters. These SHOULD reduce their responsiveness when receiving too many messages of the same class, recipient or senders. Owners of broadcasting dogs not following this rule risk prosecution under 42 United States Code 4901-4918 or similar local laws.
It is recommended that dogs are subjected to scheduled worm cures. Dogs can handle most of the usual dog viruses by themselves, and dog trojans are virtually unheard of.

Author


    P. Schaefer
    Barkley Street
    17337 Dog's Bay, 100 DB. 

    Contact: Highlander@everything2.com

Version 2004.1.0
Free replication allowed on electronic media.
Amendment allowed, provided version number is changed.




I realize that this is not as funny as publishing this on the actual RFC mailing lists, like RFC 1149, but I tried to make the best of the idea. In the effort to make this technical, maybe it got too technical. I hope though that someone will appreciate the absurdity of going into the technical details - the algorithm just might work. Scrutinize the id number of this RFC.

I like it!