Michael Thomas wrote:
stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie wrote:
BTW: we're *waaaaaaay* past last call here. This text has been here for
time immemorial.
All I propose we do is clarify the meaning of what is actually in the
draft now surrounding a
corner case. I think the bar should be a lot higher for actually
changing the text to mean
Well, it appears that we've found an interop. glitch, right?
So the spec has to be changed to clarify/fix that (since we can).
And since different coders have done different things, someone
needs to change their code as well, once we decide how to fix
the spec.
Am I missing something?
Yes. In my mind there's a substantial difference in clarifying an edge
condition
where the current text strongly implies one thing with new normative text
to the contrary. The latter requires a lot more justification, IMO --
we're way
past last call. Thus far all I've seen by way of justification is
aesthetics which
is not very good justification, in my mind. The case for keeping it is
that it
-- intentionally or not -- does the right thing through some mail
infrastructure
giving a more robust canonicalization. Why would we want to reduce our
robustness, especially at such a late date?
Those are reasonable points and you may well convince folks.
However, the rough consensus may also end up on the other side this
time, we'll see.
FWIW, I don't see this as fitting the usual "high bar" argument, since
there is a clear, even though very minor, interop issue in this case,
so while you may see one proposed solution as being done for aesthetic
reasons, and you may be right or not, there's a definite need to change
the text at least, and our way to do that is to establish the rough
consensus of the WG.
Meanwhile - are Mike's and Charles' texts the two options we want to
use to see who wants what? If so, I'll send a mail tomorrow and we can
have a poll over the holiday to see who prefers which. (Note: there's no
additional delay to RFC-dom involved since the IESG won't be deciding
base's fate until Jan 11.)
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html