Core SIR syntax rules

• Section divisions shall be used - similar to how UUEncode, PGP and many other formats work.
• Support of PGP style signatures to verify that each peer agrees with the SIR petition
• Line numbers in certain sections will be critical for signature creation - so the order data in each section will need to be strictly controlled. No peer can insert data into the middle of a section as it will break prior signatures.
• Each signature will specify the exact lines that were used in the encryption of the signature so subsequent verification is possible. This will also enable signing selective lines to prevent all-or-nothing traps which would inhibit SIR merging.
  

Section 1: Spam Incident Report -

• This top section will in effect serve as a fingerprint. The sample I made has some datum miscategorized here, but you get the idea. It will be predominantly URL based.
  
• NOTE: The client creating the SIR may need to "Click through" using a sanitized URL to see what the real server being advertised is. It would be helpfull if each peer did this to allow administrators to more rapidly identify families of SIR that all advertise the same service via relay servers.

Section 2: Supplemental Data

• Since making the sample, it occurs to me that some text will need to be re-arranged to facilitate signing & incrementing. I'll leave that for the next draft.
• Supplementatl data can contain: Client / Header spam ID information, user generated meta data added by an interactive rating process, and other content that is found to be usefull in downstream decision making but which is not suitable for a fingerprint..

Section 3: Petition Signatures

• Signature section shall allow rapid addition of signatures at the end of the list to reduce processing time to only append actions if possible.
• Signatures shall be based upon a subset of the prior section row entries. Some shall be mandatory (fingerprint data) and some shall be optional (supplemental data). In this way a peer may vouch for selective lines of data to enable subsequent processing of tabulated results.
  

Auditing:

There shall be a protocol to allow down stream random auditing back to the originating peer. For example, an administrator that wishes to confirm 1% of the signatures on a SIR report shall be able to send a compact query to a signing peer which requires a predictable answer to confirm that the signature was indeed originated by that peer and not fraudulently added.I