I was digging through the archives a bit tonight, and I realized that I'd referred to this a couple times but never actually codified it. So rather than waiting for the gent that helped me start this idea some years ago, I'm going to throw out the idea,
RFC style.
This document specifies the Standard One-Byte Restaurant
Review Protocol. This edition serves as a draft of
codifying culinary reviews, without concern for error
handling, option codes, and the security, precedence,
compartments, and handling restriction features of the
review protocol.
In many standards track documents several words are used
to signify the requirements in the specification. These
words are often capitalized. This document defines these
words as they should be interpreted in IETF documents.
Authors who follow these guidelines should incorporate
this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.
Note that the force of these words is modified by the
requirement level of the document in which they are used.
1. MUST This word, or the terms "REQUIRED" or "SHALL",
mean that thedefinition is an absolute requirement of
the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT",
mean that the definition is an absolute prohibition of
the specification.
3. SHOULD This word, or the adjective "RECOMMENDED",
mean that there may exist valid reasons in particular
circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed
before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT
RECOMMENDED" mean that there may exist valid reasons in
particular circumstances when the particular behavior is
acceptable or even useful, but the full implications
should be understood and the case carefully weighed
before implementing any behavior described with this
label.
--
The one-byte restaurant review protocol is intended to
give a standardized meaning to culinary reviews,
preserving both common definitions of criteria, as well as
offering a reader as much information as possible in the
most efficient manner.
While this specification does offer some subjectivity in
the thresholds of certain ranges, the expressed goal is to
define a central format that can be interpreted by a range of
products from diverse vendors.
--
Format:
The restaurant review protocol uses a data structure in the
form of a single byte, with the bit positions indicating
various features as shown below
0123 45 67
^^^^ ^ ^
|||| | |
|||| | \- Cost: 11: Everybody's got two mortgages these
|||| | days.
|||| | 10: One good meal is worth a week of
|||| | ramen.
|||| | 01: One good meal is worth a dinner of
|||| | grilled cheese sandwiches
|||| | 00: Woohoo! Cheaper than the unlabeled
|||| | canned food at the megalomart!
|||| \- Quality: 11: Better than sex.
|||| 10: Better than Ezra.
|||| 01: Better than dirt.
|||| 00: Better than nothing.
|||\- Formality: 1: Dress up
||| 0: At least wear something.
||\--- Take-out: 1: It's an option.
|| 0: You go now.
|\- Cleanliness: 1: What you'd hope for.
| 0: Alert the CDC.
\- Availability: 1: There's a good chance you can get
what you search for.
0: Plan for it. They might only be open
five minutes a year.
--
Example:
Many 1-byte restaurant review compatible applications may
use the hexadecimal equivalent to the binary, so a common
occurrence would be a review such as "7e" or, "01111110",
which would translate to "rarely open, clean, take-out is
available, wear the nice threads, best food you'll ever
have, non-bankruptcy expensive"
