Greetings again. Issue 1295 ("issue with relaxed body
canonicalization?") was discussed on the Jabber chat last Thursday. I
was not able to attend the chat. The resolution came out as:
Brief discussion on whether to leave it in for now, consensus is to
leave it and remove later (maybe at move to Draft Std) if it turns
out to be unused.
1295: CLOSE, no change.
The transcript, from
<http://www.ietf.org/meetings/ietf-logs/dkim/2006-06-22.html>, is:
[11:42:35] <Barry Leiba> 1295: issue with relaxed body canonicalization?
[11:42:51] <Barry Leiba> I think we decided that Sendmail will fix
this, and we won't change DKIM for it. Right?
[11:43:04] <thomasm> I don't think so
[11:43:07] <eric> i feel strongly about keeping relaxed header, but
i'm neutral on relaxed body.
[11:43:09] <Barry Leiba> Oops, wrong one.
[11:43:15] <Barry Leiba> I was thinking about header.
[11:43:16] <eric> there's no sendmail issue with relaxed body.
[11:43:19] <Barry Leiba> For body.....
[11:43:39] <eric> the main reason i can see to keep it is symmetry
with the header.
[11:43:42] <thomasm> I'm sort of weakly in favor of keeping it
[11:43:51] <sm-msk> what he said
[11:43:58] <sm-msk> what both said actually
[11:43:59] <eric> deleting it would simplify the code, but not by much.
[11:44:07] <thomasm> I'd sort of like to keep options open, though
with no good empirical reason
[11:44:10] <Barry Leiba> As I see it, we can keep relaxed body for
now, and toss it in revision (like when we move to Draft Std) if
it's not used.
[11:44:12] <sm-msk> and maybe some rewriter we haven't anticipated yet
[11:44:13] <eric> so I'm +0.1 for keeping it.
[11:44:28] <thomasm> +1 Barry
[11:44:35] <Barry Leiba> Does anyone REALLY want to toss it now?
[11:44:38] <sm-msk> i'm a little stronger for that, let's say +(2/3)
[11:45:02] <Barry Leiba> 1295: CLOSE, no change.
[11:45:08] <thomasm> I got the feeling that would have been Paul's preference
The last comment was definitely wrong (assuming that I'm the "Paul"
being referred to): I definitely think relaxed body canonicalization
should be removed from the -base spec unless there is a known use
case.
Removing the definition of relaxed body canonicalization would
simplify the base spec. It would also make one less thing for
implementers to test; this is particularly poignant because no one
seems to want to use it, so we won't have good test cases.
If we remove the definition of relaxed body canonicalization, and a
use case comes up later, someone can write an extension document
defining it (and, hopefully, include examples). The "c=" tag would
still allow body canonicalization, so an extension doesn't involve a
new tag.
Absent a use case that the WG agrees on, we should take this one out.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html