No comment means I'll roll it in somehow...
Jim Fenton wrote:
With apologies that this didn't get done before (I think) the last day
of WG last call, here are my comments on ssp-requirements-03.
1. Introduction
"first party" is used here before being introduced. Should probably
either refer ahead to the glossary or use a term like "author" that is
less jargony.
"a priori" is overused, perhaps inappropriately. Suggest s/there is no
expectation of a priori knowledge/there is in general no knowledge/
Also "a priori invalid" doesn't make sense, because it was observed, and
we haven't defined what "invalid" is.
2. Definitions
s/Listid/List-id/
s/adjacent SMTP./adjacent SMTP server./
3.1
My first problem is with the title of this section: Is "All Mail Signed
with DKIM" really a problem scenario? I think the problem scenario is
really that an unsigned message was received, and the recipient has to
figure out what to do about that.
s/insured/ensured/
Paragraph 2, "what their expectations are for unsigned mail." sounds
like a question about that this domain does with their incoming mail,
not what their practices are with respect to signing.
How about "what their expectations are for unsigned mail purportedly
originating from their domain". It's not strictly a practice per se,
it's what their expectations are wrt the ultimate survivability which
is not something that they control (= practice).
Paragraph 3, s/allowed/allows/
Paragraph 5, s/bias filters/bias its filters/
Following paragraph 5 is a numbered list of steps that should be
preceded by some introductory text.
Step 1, s/purportedly sends/is sent/
Step 4, "looks somewhat more suspicious" sounds like a UI issue, and
conflicts with the definition of Suspicious that we're likely to be
using in the SSP draft itself
First it doesn't have to have anything to do with a UI, and second
I'd say that you have it cart before horse here about suspicious:
if there's a problem, you need to tell me what it is, not that it
conflicts with the ssp draft.
.
3.2
Paragraph 1 first sentence is worded as though a particular class of
mail is the target; the domain is actually the target.
I'd say that's debatable. It is transactional mail that is the prime
problem, not the day-to-day conversational mail. Whether those two
coincide is largely a question of how you lay out your namespace.
Paragraph 2 should perhaps mention the usage patterns of such domains,
that they don't typically send to mailing lists, which are a significant
contributor to signature breakage.
Paragraph 3 Informative Note: Isn't this whole document informative?
(Applies to other informative notes too)
No, the document still lays out normative behavior for the protocol.
PS, etc are for actual protocols. Also: plenty of informational rfc's
have normative language.
Again, the numbered list of steps could use some introduction.
Step 4, same comment about use of "suspicious".
4.2
SSP's is awkward; I would word things to avoid this ("Sender Signing
Practices's" is a mouthful!) Same comment elsewhere.
Paragraph 1, s/SSP's client will generally be deployed/SSP lookups will
generally be performed/
The 4844.From address isn't a "trust basis" but rather a key (in the
database sense, not the crypto sense) to the policy.
I'm not groking this.
Where does this section talk about determinism (first word of the title)?
4.4
Paragraph 3, "strong practice" isn't defined anywhere. You might want
to say "signing complete" practice or something like that.
4.5
I'm not sure "transport scenarios" fits that well with the content of
this section.
Suggest away...
Paragraph 2, s/sadly a vector for those sending mail for anti-social
reasons/unfortunately an attack vector for those wishing to spoof email
addresses/
4.6 through 4.9
Are these really deployment scenarios? They don't read that way to me.
If you can think of another bucket to put them under... I mainly didn't
want to get too elaborate on the taxonomy.
5.1
Item 4, "The process of obtaining the parent domain's practices MUST
complete..." is a duplicate of item 2. The following sentence, "In
widening the scope..." isn't a requirement at all but a discussion of
implementations.
This is going to get rewritten in 2, so it probably won't be a dup after
5.3
The whole thing about the X-Silly header field makes it sound like there
is a requirement here that SSP has to be able to publish expectations
about presence of header fields. Is that requirement intended?
Yeah, I'll reword this.
Item 1, do you mean the entire RFC2822.From address or just the domain
part?
just domain.
Item 2 sounds like a requirement for the protocol but really it's a
requirement that the specification define this, correct?
yes.
Item 6 should also mention the ability of the domain holder to delegate
individual keys by registering them. Isn't there something else we can
reference that describes the way to do this delegation?
Registering them?
Item 6 doesn't reference any scenarios. I think it refers to Deployment
Scenario 1
.
Item 10, I disagree that this requirement should stand.
5.4
Item 1, s/able to extend/extensible/
6.
Item 1, where is the requirement?
Good question :)
Mike
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html