I'd still like it left in and if it's unused or providing no value, to
remove it
at DS.
Mike
Barry Leiba wrote:
Paul Hoffman said (abridged):
[11:42:35] <Barry Leiba> 1295: issue with relaxed body
canonicalization?
[11:43:07] <eric> i feel strongly about keeping relaxed header, but
i'm neutral on relaxed body.
[11:43:42] <thomasm> I'm sort of weakly in favor of keeping it
[11:43:51] <sm-msk> what he said
[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: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:38] <sm-msk> i'm a little stronger for that, let's say +(2/3)
I definitely think relaxed body canonicalization should be removed
from the -base spec unless there is a known use case.
As we can see from the jabber-log excerpt, there are three opinions to
keep "relaxed body", but they're weak (Murray is the strongest, and
he, too, is waffling). Paul, on the other hand, is strongly in favour
of dropping it.
The decision from the jabber meeting was to keep it, thinking that we
could drop it later if it turns out not to be used. Paul correctly
points out that we could just as well drop it, and put it in later if
it turns out to be needed.
I'd like to see other participants weigh in; please do not remain
silent and assume anything about what Stephen and I will take that to
mean. I'd especially like Eric, Murray, and Mike to say whether
they're swayed by what Paul said.
For what it's worth, I agree with Paul. If those who've been running
this stuff haven't found a real need for "relaxed body", why don't we
fall on the side of simplification?
Barry
--
Barry Leiba, Internet Messaging Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
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