SNP 2 builds on SNP 1 by introducing a much easier request structure, dropping the need for awkward separator characters, and introducing a more familiar URI-style approach. Additionally, SNP 2 provides full access to the Snarl raw API (albeit with some limitations) making it - unlike SNP 1 - relatively future-proof.

While superseded by later versions of SNP, SNP 2 is not considered deprecated. No further development on the protocol is planned, however as the protocol allows access to the raw Snarl API, future additions to the Snarl API will usually automatically be available in SNP 2. As such, there is no plan to retire SNP 2.

Two types of message are defined: Request and Response.

A valid SNP 2 request must contain a header, a command, and the terminating character. It may also contain one or more arguments.

Always snp://

Any valid Snarl API command (see limitations below)

Each argument must contain a key and value separated by an equals sign. Multiple arguments must be separated by ampersands. Valueless arguments are not permitted. If arguments are supplied, the first argument must be separated from the command by a question mark.

Always \r (ASCII character 13)

snp://{command}[?key=value&key=value&key=value]\r

Note the similarity between a SNP 2 request and a raw Snarl API request.

snp://register?app-sig=foo&app-title=Bar\r

A SNP 2 response is a single line of information separated by forward slashes:

SNP/{version}/{status code}/{status text}[/<data>]

version is the latest version of SNP 2 supported by the Snarl instance that communications are taking place with. Communications with Snarl typically take place using an agreed protocol on an agreed port – there is currently no concept of a client being able to ‘version up’ - hence a client can determine what version of SNP is available on a certain port by issuing the version command, which will return a version-specific SNP error message.

SNP/2.0/0/OK/464

SNP 2 does not support subscriptions or notification forwarding. Attempting to issue a subscribe request will result in an error – typically BadCommand - although this may vary depending on individual implementation.

Argument values which contain ampersands and equals signs must be encoded before being sent to Snarl, otherwise the characters will be misinterpreted as argument and key/value breaks respectively. Ampersands can be encoded as && and equals signs can be encoded as ==, or they can be URL-encoded (for example, %26 and %3D respectively).