Name: <tag name>
Status: <required/strongly suggested/suggested/optional/reserved>
Suggested restriction: <indirect only/admin/privileged/everyone/other>
Purpose:
<purpose description>
Syntax:
<description of syntax>
Examples:
<examples of valid output>
Suggested rendering:
<examples of how it could be rendered>

Name: oc
Status: required
Suggested restriction: indirect only
Purpose:
Display a literal opening character
Syntax:
{oc}
Examples:
{oc}
Suggested rendering:
A literal { character.

Name: cc
Status: required
Suggested restriction: indirect only
Purpose:
Display a literal closing character
Syntax:
{cc}
Examples:
{cc}
Suggested rendering:
A literal } character.

Name: bc
Status: required
Suggested restriction: indirect only
Purpose:
Display a literal bar character
Syntax:
{bc}
Examples:
{bc}
Suggested rendering:
A literal | character.

Name: hey-client
Status: strongly suggested
Suggested restriction: indirect only
Purpose:
Client directives (anything that changes the future behavior of the
client) should only ever appear inside a hey-client tag. A hey-client
tag should never be generated directly from softcode. This increases
the security of directives in general, and prevents the use of
directive tags the MUSH doesn't yet know about to influence clients
that do support them.

In addition, it hides the rendering of directive tags even if the
client doesn't know about them, reducing the odds of outputting text
that is meant solely as a client instruction to the end user.

Even if a client doesn't support any directives, it is strongly
suggested to implement this tag. In this case the tag would do nothing
special, but still hide its contents from the end user.
Syntax:
{hey-client|{directive-tag ..}
            {directive-tag ..}
            ...}
Examples:
{hey-client|{escape []()\{oc}{cc}|\}}
Suggested rendering:
Actively hide all the contents of the tag, rather than displaying the
contents as per a typical tag.

Name: color
Status: suggested
Suggested restriction: indirect only or everyone
Purpose:
Allow color to be applied to the tag's contents.

This tag could either be treated as indirect only, and be handled
entirely though, for example, the ansi() function on a MUSH. Or it
could be left unrestricted, with the understanding that (likely) there
will be no fallback mechanisms if it is used in this fashion.
Syntax:
{color <fg> <bg>|<text>}

fg and bg are color specifications for foreground and background, to
be applied to the text. The specifications would default to html style
hexadecimal #rrggbb values, but could be something different if the
client has indicated a capability to handle other values.

A special value of -, or a value that has been omitted means no
change. (Input required: Should - mean 'reset to default' instead? Or
should an additional character be added to cover that, perhaps?)
Examples:
Roses are {color #ff0000|red}, violets are {color #0000ff|blue}.
{color #ffff00 #ff0000|Danger!}
{color - #ff0000|Red background.}
Suggested rendering:
The text marked up with appropriately colored foreground and
background.

Name: exit
Status: optional
Suggested restriction: everyone
Purpose:
Denoting that a piece of text represents an exit.
Syntax:
{exit <shorthand>|<description>}
or
{exit|<description>}

If a shorthand is specified, it is implied that it can be used to
uniquely identify and use the exit.

If no shorthand is specified, it is implied that the description
should be sufficient to identify and use the exit.
Examples:
{exit|south}
{exit w|West <W>}
{exit #123|Somewhere else}
Suggested rendering:
As normal.

Name: 
Status: 
Suggested restriction: 
Purpose:

Syntax:

Examples:

Suggested rendering: