>> Page 11, informative implementation note at the bottom of the page: >> Delete it. If we want to support EAI, we should support EAI, but >> this language just encourages code that won't interoperate. > >I don't see anything on page 11 about EAI, nor any informative notes.
Oops, that's page 12, the note about UTF-8 at the bottom. >> Page 17, informative implementation note at the top: Delete message >> editing language "or remove text that appears after the specified >> content length, perhaps based on other criteria" > >Agree. (Though I see that on page 18) Right, it's p.18. (It was pretty late, one number starts to look a lot like another.) >> Page 24. first pp: delete "or MAY choose other means of representing >> its users." An AUID need have no relationship to any user. Some of >> my AUIDs refer to web scripts and mailing lists. > >Actually I think that whole sentence is redundant to the earlier text of the >paragraph. OK with me. >> Page 24, informative note: suggest deleting, again because AUID need have >> no relation to any user. Or perhaps rewrite as: >> >> INFORMATIVE NOTE: The Local-part of the "i=" tag is optional. >> It can include the domain part without the Local-part of the >> identity. > >Since there are a lot of reasons one might wish to leave out the >local-part (don't know, don't want to say, don't feel like it), I'm >fine with being this simplistic. Maybe what you have, but tack onto >the end "if the signer is unable or unwilling to specify a value >there"? Sure. >> Page 24, informative discussion: delete everything after the second >> sentence, since it doesn't help robustness or interoperability > >I could live with it being out, but I like it in there if only to document our >deliberations so others later won't have spend the energy to go down the same >path. Hmmn. Do we want to say "DKIM doesn't identify individual users so don't try to make it do that?" If so, it's probably better to put somewhere closer to the top. >> Page 27, x= first informative note: delete, doesn't help robustness or >> interoperability. (Neither does x= but that's a lost battle.) > >I'm not even sure I understand that remark. Can someone remind us of what it's trying to say? We had long arguments in which some people argued that one could keep bad guys from replaying messages by making the x= time short enough. >> Page 28, z= last pp: it says that header fields " SHOULD be converted >> as described in MIME Part Three [RFC2047]." That document describes >> encoding of specific character sets such as ISO-8859-1. What >> character set is it supposed to use? > >Interesting. I suppose it should be just basic DKIM-quoted-printable >conversion, meaning this whole paragraph can go except perhaps to >indicate that even eight-bit data can be thus represented. This is one of those places where I don't know how much we can change without the IESG deciding to recycle. Just saying to use QP isn't adequate, since then you couldn't tell whether =BD is the 1/2 symbol in 8859-1, the oe ligature in 8859-15, or those three characters. My inclination is just to take it out, since at this point the 5322 rules say that any non-ASCII should already be MIME-encoded in the headers that z= copies so there shouldn't be anything to downcode. >> Page 29, sec 3.6.1, first pp: delete, since it doesn't help robustness >> or interoperability. >I had to think about this one for a while. Would it even be >appropriate to describe this as the DNS Text Representation, rather >than just Text Representation? We might do it a different way in >HTTP without XML, for example. There was a bunch of quite hypothetical discussion of other ways to represent and serve keys, none of which ever amounted to anything. That's why I'd rather wait until there actually are other kinds of keys before describing what they are. >> Page 29, description of v=, last sentence: compare that to the note on >> page 20 that I suggested deleting. > >Not sure what you're saying here; did you want that last sentence out? It's saying that if, 1.0 != 1, so much for increasing arithmetically. This language is fine. (My preferred order is 5, 2, 8, 9, 4, 7, 6, 3, 1, 0, which is of course alphabetical order in French.) >> Top of page 36, first sentence. If we leave in the message editing >> stuff, change to "Hence, DKIM's mandatory output to a receive-side >> Identity Assessor is a single domain name and a possibly edited >> version of the message that has been verified." > >I don't like the edited version stuff. I'd prefer it to be positioned as an >explicit >indication of what fields and portion of the body were signed. If we agree that's an explicit output, that'd be a rather large change to the spec. My DKIM verifier Mail::DKIM just says yes or no, perhaps with a note about whether failure was DNS related or one of the hashes not matching. >> Page 36, informative discussion: delete it, since as far as I can tell >> what it says is "we don't know what if anything an AUID will be used >> for." > >I'd rather say that explicitly, even if more concisely. It's better to say >that than >say nothing and leave them wondering why we didn't say anything about it. OK. >> Page 39, first line: "failed" -> "invalid" to be consistent > >Actually I find that sentence structure weird. How about: > >Verifiers SHOULD treat invalid signatures as though they were not >present in the message. OK. >> Page 40, informative operations advice at the top: do we believe this >> advice to keep a verification key around until the recipient reads >> the message? I think in other discussions we've agreed that the key >> should be valid for the maximum delivery time, not until someone >> reads his mail which could be months. > >What's "the maximum delivery time"? Are you talking about "x="? (I suspect >not...) RFC5321 recommends "at least 4-5 days" as the time to keep retrying a delivery before giving up. That's what I had in mind. >> Page 42, informative admonition: I don't understand what we're supposed >> to do with this advice, which appears to be intended for the authors >> of relay MTAs. Perhaps to make this operational, it should warn signers >> that signing multiple fields makes it more likely that the signature >> will break due to gratuitous reordering, as it says in sec 8.11. > >Within context, I take it to be a warning against signing trace header fields >like >Received. But I agree that its presentation is a little ambiguous. We give that advice in other places, so we can probably do without it here. >> Page 45, second pp of section 6: shouldn't this refer to RFC5451 rather >> than just "a verification header" ? > >I think the idea is that RFC5451 is one example of an annotation system, so "a >verification header field such as the one described in RFC5451" would probably >be fine. OK. >> Page 49, item 4: does any implementation really cycle through multiple >> key records? The one I use (Mail::DKIM) doesn't. Suggest limit of >> one key record per selector with undefined results otherwise to improve >> interoperability. > >Ours barks if more than one TXT comes back without checking any of them. That >said, >what about saying "MUST process one, MAY process the rest or MAY return an >error if the >first one was no good"? Unless someone has an implementation that does something with multiple TXT records, I'd prefer to change the text to match the code. >> Page 62, sec 8.13: since we've agreed that the SDID rather than the >> AUID is the primary identifier, how is this section useful? Suggest >> deleting it. > >Hmm. The AUID isn't primary, but that doesn't mean there aren't possibly >interesting >semantics there, especially since we're not talking about the local-part. >Since it's >informative, I don't see that it steers anyone wrong to leave it in there, >again >relying on my earlier feeling that I'd rather opt to relay some non-normative >discussion than nothing so that later people aren't wondering why we weren't >totally >silent on the matter. There was a long argument here, too. One side argued that subdomains are entirely at the mercy of parent domains since that's how delegation works, the other argued that there are cut points like gTLDs where the parent is different from the subdomain, although they admitted there is no reliable way to tell where those cut points are, nor exactly what the problem was. (You can probably tell which side I was on.) >Thanks for the fine-toothed comb! You're quite welcome. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
