Ted,
Ted Hardie wrote:
I believe the text here:
Since experimentation resulted in significant Internet deployment of these
specifications, the DKIM working group will make every reasonable attempt to
keep changes compatible with what is deployed, making incompatible changes only
when they are necessary for the success of the specifications.
implies the need to be clarify the charter in two ways. The charter needs
> to reaffirm that the IETF has change control over the specifications
> at this point, so that there is no question over who gets to decide
> whether an incompatible change is necessary.
I think that this is motherhood and apple pie, and would have no
objection to inclusion of a reasonable statement along these lines.
But it might take a while to agree what's "reasonable" and since
Dave's right that this would be a kind of impactless change
to text that did take some time and effort already, I'd rather not
have a prolonged discussion on the topic.
Meanwhile, as a point of fact, the DKIM specification has already
changed in one on-the-wire incompatible way (canonicalisation), as
a result of a bug. I also expect another wrt. hashing since sha-1
is probably not the right thing to use anymore. So, there is an
existence proof that the current set of authors are willing to
change the specification in response to review.
(The suggestion that all charters have some implicit boilerplate
that'd include such IETF change control phrasing does sound like
a reasonable thing to discuss sometime.)
The charter also needs to indicate that the working group will
> consider the relationship of this work to other, existing IETF
> technologies. That does not imply that it needs to adopt them,
> but explaining why it chose to use, for example, this signature
> mechanism rather than one of the existing ones would help the
> IETF understand whether this mechanism is a better point
> solution, implies a problem with the existing mechanisms which
> should be fixed in the existing solutions, or should be considered
> as the basis of a more wholesale replacement.
Just checking. You're referring to the "why not s/mime" question
here, right? I think answering that question is reasonable (and
has a good answer). The putative DKIM WG is not however the
place to expect an answer to "why don't we all use s/mime" as
I'm sure you agree. Its quite possible that answer to the
first question might help answering the second one, but I
wouldn't want to raise too many expectations.
(BTW I fully agree with what Barry said on this too.)
Doing so in its first milestone document seems like a reasonable
> way to accomplish this, but doing so in the standards-track
> specifications also seems reasonable.
Well, we included an overview deliverable which is intended to
capture all that kind of stuff. Its the last deliverable but
of course that doesn't mean that that particular piece of
text won't exist earlier. If you're thinking that the IESG might
want to see/discuss the "why not s/mime" answer during IETF
last call on the protocol spec, I guess that's reasonable.
Requiring that that answer be part of the last-call document
or the threats document doesn't seem like the best way to
handle this though.
Stephen.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf