DRAFT ZIP: #105 - This ticket is being addressed by a draft ZIP specification. If you are interested in this topic, please contribute to that specification.

Our current memo field content specification reads like this in the protocol spec version 2016.0-beta-1.10:

The usage of the memo field is by agreement between the sender and recipient of the note. The memo field SHOULD be encoded either as:

• a UTF-8 human-readable string [Unicode], padded by appending zero bytes; or
• an arbitrary sequence of 512 bytes starting with a byte value of 0xF5 or greater, which is therefore not a valid UTF-8 string.

In the former case, wallet software is expected to strip any trailing zero bytes and then display the resulting UTF-8 string to the recipient user, where applicable. Incorrect UTF-8-encoded byte sequences should be displayed as replacement characters (U+FFFD).

In the latter case, the contents of the memo field SHOULD NOT be displayed. A start byte of 0xF5 is reserved for use by automated software by private agreement. A start byte of 0xF6 or greater is reserved for use in future Zcash protocol extensions.

Let's begin a use case study with early users, eg exchanges, wallets, embedded apps, wrt to how they would like to use the memo field and begin proposing a standard.

Is it true that third parties wishing to implement their own "app specific / non-standard" protocols should use 0xF5 as the initial byte with no further restrictions on subsequent bytes?