Yet more suggestions:
4.1 DNS Representation
"Sender Signing Practices records" -> "Sender Signing Practices
Records" (assuming you agreed to the previous suggestion of making this
an explicit definition change in 2.7).
"Records not in compliance with that syntax or the syntax of
individual tags described in Section 4.3 MUST be ignored" This seems
like you're saying two things: First, records with overall syntactic
problems (like SPF record put into SSP location) should be ignored.
Second, that records with individual tags that are not syntactically
correct result in the entire SSP record being ignored (rather than the
specific tag in question being ignored). Is this what you mean?
"for purposes of message disposition," - I would just delete this
bit as it's not necessary and could stur up the distaste some have with
the entire question of SSP determining message disposition.
"SSP records for a domain are published at a location...." - I
keep forgetting where this is and trying to find it in the document is
not as easy as it could be yet this is a major issue of practicality. I
think this is just my own stupidity coming into play but perhaps this
point could be highlighted with a 4.1.1 and a title of like "SSP
location in DNS" and maybe it should be put into 4.2 since that section
is entitled "Publication of SSP Records".
4.2 Publication of SSP Records
I see we have done away with the tree-walking completely which I
think is great.
4.3 Record Syntax
So, if I encountered an SSP record with dkim=foo this value is
invalid and so the SSP contains a tag that is syntactically incorrect.
This causes the rejection of the entire SSP record right? If so, I
think this should be made more clear because I missed it. Is this what
the text in 4.1 is saying?
The descriptive text for "all", "strict", "process" should be indented
some to aid readability.
Non-Normative Rationale: Strict may also be used by domains who
simply don't want their domain spoofed. Not sure if you want to say
something about that or not.
The section on "process" says that messages "SHOULD be processed by
the verifier" - that's good because this is what got us the result of
"process" in the first instance :P
Suggested rewrite:
process - Messages which are Suspicious from this domain SHOULD
NOT be rejected although an SSP failure MAY be considered in subsequent
evaluation of the message.
"intende" -> "intended"
Suggested rewording of the t=y text:
"The domain is testing Sender Signing Practices and the message
SHOULD NOT be considered Suspicous based solely on it's results."
That's it from me for nits :)
Arvel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html