Replies inline...
Michael Thomas wrote:
No comment means I'll roll it in somehow...
Jim Fenton wrote:
3.1
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).
Good; that makes it clear you're talking about outgoing mail.
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.
It was the word "looks" that bothered me. How about, "...such that it
treats the message with additional caution." That avoids the s-word
entirely (although in fact it probably doesn't matter).
.
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.
Fair enough; you're focusing on the class, which is legitimate, and I
was focusing on the messages themselves.
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.
But this is a requirements document, not a protocol specification itself.
4.2
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.
"Trust" is such an overused word that I would prefer the wording,
"...will be used as the reference point from which to fetch the
published information."
4.5
I'm not sure "transport scenarios" fits that well with the content of
this section.
Suggest away...
How about "Caching Considerations"?
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.
I would just have them in the Requirements section; I don't think
everything that is a requirement needs to be traceable to a scenario.
Security, for example, isn't a scenario because you always need it; it
isn't independent of the other scenarios.
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?
Sorry, bad choice of words on my part. I mean that the domain holder
can publish a key record corresponding to a key under control of someone
else (an email service provider, for example).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html