Just a few small suggestions:
1) In several places the language "SHOULD be considered non-Suspicious"
is used. This seems an awkward way to say it. Since the term
"Suspicious" is defined in section 2.8 "SHOULD NOT be considered
Suspicious" might be a better way? Also "MUST be considered
non-Suspicious" -> "MUST NOT be considered Suspicious"?
2) Section 3 bullet point 3 - "and SHOULD have a Valid Signature from
this domain" -> "and SHOULD have a valid Originator Signature"
3) "not to be legitimate" -> "to be illegitimate"
4) ", and any verifiable signature is present from some signer other
than the Originator Address in the message" -> "and the message contains
a Verifier Acceptable Third-Party Signature"
5) "SHOULD NOT be considered to be Suspicious" -> "SHOULD NOT be
considered Suspicious"
6) Section 4.1 - perhaps this is a better way of stating the second
sentence in the NON-NORMATIVE DISCUSSION paragraph:
"Many DNS server and resolver implementations are incapable of quickly
and easily supporting new resource record types. For this reason,
support of TXT records is required whether a new RR type is defined or
not."
7) Section 4.1 states that syntactically incorrect SSP records should
be considered as NODATA. This is different from the 4871 approach of
simply ignoring unknown tag/value combinations. This also precludes the
ability to extend an existing SSP record with some future new tag
(should that need ever arise). Was this intended? It seems to
contradict what's stated later in 4.3 that unknown tags are to be ignored.
8) "whcih" -> "which"
9) "Originating Domain" is used as if it was one of the previously
defined terms but it isn't.
10) "and its all of its" -> "and all of its"
11) Personally, I like the suggestion someone else made of changing
"unknown" to "?" but this isn't particularly important really.
12) Section 4.4 - "including any where the Alleged Signer is" -> did
you mean "including anywhere the Alleged Signer or"
13) Algorithm 2 - "to the domain part of the Originator Address" - it
seems like you'd want to define "Originator Domain" in the definitions
section and use that in a few places.
14) Algorithm 2 - "with one or more answer which is a
syntactically-valid SSP response" -> "with one or more syntactically
valid SSP responses"
15) Algorithm 3 has me a little worried. It would prevent the use of
domains unless they explicitly exist in DNS. So, if I wanted to send a
message out from message(_at_)sms(_dot_)altn(_dot_)com I would have to make sure and
create a DNS A record or something for sms.altn.com first right?
(sorry, my knowledge of DNS is not so good)
16) Algorithm 4 - "of the domain part of the domain part" -> "of the
domain part" this is another case where defining Originator Domain in
advance might be helpful.
17) Algorithm 4 - "is a top-level domain" how can that be determined in
practice? I don't think it can can it? If not, we're giving algorithmic
instruction here that is impossible to implement.
18) Algorithm 5 - unless we can figure out how to stop queries at
top-level domains, Algorithm 5 will send lots of queries to the root
servers right (.co.uk for example)?
19) Algorithm 8 - "and one or more Valid Signatures are present" ->
Valid Signatures doesn't say enough here. In this case a valid
Originator Signature or a valid Verifier Acceptable Third-Party
Signature" is what you want.
Arvel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html