The NoCeM Registry's Policy

Spoolability Policy
Issuer Listing Policy
Permissioner Listing Policy

Although amenable to Usenet community influence and consensus, this policy and the way we apply it ultimately reflects our humble opinion and judgment. If you don't like our policy, see NoCeM Permissioners for alternatives by others (and possibly a place for your policy, too); see also How to Use The NoCeM Registry.

We reserve the right to use our judgment in cases where criteria in this policy conflict with each other or would lead to an obviously undesirable or silly result. Also, this policy is evolving and we update it at times. The latest version will always be available from this page.

Spoolability Policy

For our default NoCeM permission file, we apply the following criteria for a permission entry of yes:

Issuer must not have indicated an own preference for a no default permission entry. (In other words, we will observe an own preference for a no entry.)
Issuer or their type should not be newly listed in The NoCeM Registry. (In other words, newly listed issuers should expect to be initially listed with a permission entry of no.)
Issuer should have published (in the newsgroup news.admin.nocem*) a NoCeM policy statement, supplying all necessary information as listed below. (Retroactively, an issuer may have published such a policy statement.)
Barring exceptional circumstances, issuer should stick to their stated criteria and scope.
Issuer should not have declined any and all responsibility for their notices.
There should not be objections ('semivetos') raised* by two or more other issuers listed with a permission entry of yes.
There may be recommendations by other issuers listed with a permission entry of yes.
Issuer may have a record as a proper canceler* using third-party cancel messages.
Issuer should include in their NoCeM messages accountability information* for each article marked for deletion, such as contents of original From header, reason for deletion and, when applicable, spam index value. Information which is the same for all articles in a NoCeM notice or NoCeM message may be supplied only once.
Issuer's PGP key used for signing their NoCeM notices must be compatible with the oldest PGP versions commonly used with software such as NoCeM-On-Spool (currently versions 2.6.*).
For yellow or red color-coded deletion criteria, these must be anchored in evidence for audience support, such as a newsgroup charter or hierarchy FAQ stating articles in question as eligible for deletion or as tantamount to net abuse.
Issuer's deletion criteria and scope interrelate as follows (to be read as: 'a global issuer should have a green – i.e., consensus only – criteria entry', et cetera.):

Criteria (color-coding) Scope	Green Criteria entry	Yellow Criteria entry	Red Criteria entry
Global issuer (i.e., Usenet-wide, alt.*, etc.)	should have	should not have	must not have
Local issuer (i.e., geographical hierarchy, individual newsgroup, etc.)	may have	may not have	should not have

When in doubt

For global issuers: when in doubt, no.
For local issuers: when in doubt, yes.

Issuer Listing Policy

We apply the following criteria to determine whether to list a NoCeM issuer in The NoCeM Registry:

We must be able to find the following information on issuer:

'Issuer' entry to be used in NoCeM permission file (we will, if necessary, use a substring at most 20 characters long)
contents of 'Type:' NCM header used in their notices
PGP public key used for signing their NoCeM notices (see also above).

Issuer should supply* – in their policy statement, their NoCeM messages or otherwise – the following information:

repliable e-mail address
criteria used for their types of NoCeM notices (a mere mention of 'spam' does not suffice)
scope of their activities, i.e., part of Usenet their notices are normally targeting (e.g., all of Usenet, a geographical hierarchy, or one or more individual newsgroups)
URL directly to an ascii-armored version of their PGP public key used for signing NoCeM notices.

Issuer may supply the following information, as seems applicable:

preferred 'Name' entry (we reserve the right to truncate or abbreviate)
URL to a website version of their NoCeM policy statement (see above)
own preference for a no default permission entry, which we will observe
URL to a website version of a FAQ or charter pertaining to their scope.

Information provided should be in English, or at least in a language we can read*.
Issuer should be actually issuing NoCeM notices. Volume is immaterial. We usually delete an issuer's entry after they have been inactive for several months, but exceptions either way are by no means rare.
NoCeM notices should be posted to at least the newsgroup news.lists.filters.
Contents of the 'Action:' NCM header used in issuer's notices must be 'hide'. (We don't list 'show' notices.)
Issuer's NoCeM notices may be 'spoolable', i.e., at least remotely suitable for honoring with the effect of deleting articles from news servers via software such as NoCeM-On-Spool. We reserve the right to cut down on listing clearly non-spoolable issuers or types, especially ones that may turn out to be ephemeral.

When in doubt

Issuers will be listed on a basis of: when in doubt, yes.

Permissioner Listing Policy

We apply the following criteria to determine whether to list a permissioner – i.e., a supplier of a NoCeM permission file or of the information underlying one – in The NoCeM Registry:

Permissioner's file (or data) should be seriously intended for actual use on spool on a server of a site with sincere and bona fide intentions. Other than that, we will be happy to list permissioners with whose policies we sharply disagree.
Permissioner should update their information regularly.
Permissioner should supply* the following information:

URL to a properly formatted NoCeM permission (ncmperm) file, i.e., one that would work with common NoCeM-On-Spool software (see ours for an example)
repliable e-mail address.

Permissioner may supply the following information, as seems applicable:

preferred 'Permissioner' entry (we reserve the right to truncate or abbreviate)
URL to an explanation of their policy for a permission file entry of yes (see ours above for an example)
preferred 'Characterization' entry (we reserve the right to edit for length and clarity)
URL to a PGP keyring with public keys of issuers in their permission file (see ours for an example).

Information provided should be in English, or at least in a language we can read*.

When in doubt

Permissioners will be listed on a basis of: when in doubt, no.