Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)
On Jun 16, 2009, at 2:35 PM, Michael Thomas wrote:
1) People saying that d= is THE IDENTIFIER are overloading the
value: d= a routing
label to a particular DNS subtree. Whether it has anything to do
] Modified Introduction text for rfc4871-errata (resend)
tThis update resolves that confusion. It defines
additional, semantic
labels for the two values, clarifies their nature and
specifies their
relationship. More specifically, it clarifies that the
identifier
Are you trying to say?
DKIM_RESULT = DKIM_VERIFY(ENVELOPE, PAYLOAD)
FINAL_RESULT = DKIM_ASSESSOR(DKIM_RESULT, DKIM_TAG_QUERY(D) )
-- minimum requirement?
I don't fully understand your notation, but I think what I'm saying is that a
minimal DKIM implementation provides what's in
Bill,
The word default means that an alternative can be specified. Within the
formal specification that's not what is normatively provided for, per the
errata/update clarification. There is no mechanism for specifying an
alternative source for the primary, delivered identifier.
Within the
Specification of reputation systems would be in violation of the
charter, but e.g. the recently completed dkim-overview draft does
talk about the boundary between DKIM and assessment systems.
Certainly the intent of this text (rephrasing the Introduction in
draft-ietf-dkim-rfc4871-errata) was
excellent. that's certainly a simple enough way to resolve the concern.
d/
bill.ox...@cox.com wrote:
I don't have a specific objection to the word reputation per se but
assessment is a more neutral term for this particular group so
s/reputation/assessment/g should work.
--
Dave Crocker
Jim Fenton wrote:
Finally, will you be taking this proposed text to the ADs who had
concerns to determine whether this addresses their concerns? I'm
wondering whether they expected a change to be made, since none of them
raised a DISCUSS on this issue (Cullen abstained).
I am planning to
First thanks to the WG for trying to address the problem I had raised.
I had assumed nothing would be done to try and correct so I just put
abstain as clearly some people felt the document was worth publishing
but as we are trying to fix or clarify this, let me be more explicit.
My focus
Introduction text for rfc4871-errata (resend)
Jim Fenton wrote:
I do have a problem with the last paragraph:
tFor signers and assessors that have been using the i= tag for
reputation assessment a software change to using the d= tag is
intended.
/t
and some
Dave CROCKER wrote:
excellent. that's certainly a simple enough way to resolve the concern.
d/
bill.ox...@cox.com wrote:
I don't have a specific objection to the word reputation per se but
assessment is a more neutral term for this particular group so
s/reputation/assessment/g should
-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On
Behalf Of Michael Thomas
Sent: Tuesday, June 16, 2009 12:34 AM
To: dcroc...@bbiw.net
Cc: pasi.ero...@nokia.com; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)
Will somebody
Thomas
Sent: Tuesday, June 16, 2009 12:34 AM
To: dcroc...@bbiw.net
Cc: pasi.ero...@nokia.com; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)
Will somebody please tell the editor that this still violates our charter
since reputation is out
On Tue, Jun 16, 2009 at 11:49 AM, Dave CROCKERd...@dcrocker.net wrote:
Dave CROCKER wrote:
excellent. that's certainly a simple enough way to resolve the concern.
d/
bill.ox...@cox.com wrote:
I don't have a specific objection to the word reputation per se but
assessment is a more
At 08:00 16-06-2009, Cullen Jennings wrote:
My focus is mostly on what this errata means to implementations in the
field. That would be implementations of both DKIM the narrow signing
protocol and implementations that use the information DKIM provides. I
think the document should be clear on
The
Jim Fenton wrote:
I do feel that we're effectively
using assessment as a proxy for the R-word which goes back to the
concern I voiced long ago about not requiring the verifier to pass on
other values including i= if they're present. It seems to me that this
is effectively dictating the
Dave CROCKER wrote:
Meant to include this, for completeness:
Replacing 'reputation' with 'assessment', here's the latest version:
I'm better with this version; thanks. I do feel that we're effectively
using assessment as a proxy for the R-word which goes back to the
concern I voiced
On Jun 16, 2009, at 10:51 AM, SM wrote:
At 08:00 16-06-2009, Cullen Jennings wrote:
My focus is mostly on what this errata means to implementations in
the field. That would be implementations of both DKIM the narrow
signing protocol and implementations that use the information DKIM
Cullen,
This is why I still have some faith in the IETF process, common sense
engineering generally prevails or highlights the problem areas. Thanks.
My apology if the following inline comments goes beyond what you seek,
but I believe it summarizes an Implementor's engineering viewpoint for
DKIM's purpose has been lost with the continued out of scope undefined
reputation modeling. A concern raised over and over again, Assessment |
Reputation - wink wink, same thing when it come to coding it. Word
smithing does not solve implementation issues.
I don't agree at all with these
Hi Murray,
I do not at all disagree with you. Your black box functional model is
one we have modeled as well.
However, IMO, in principle the framework must stand on its own for
general implementation and not depended on other separate or augmented
technologies to achieve some level of
Murray S. Kucherawy wrote:
DKIM's purpose has been lost with the continued out of scope undefined
reputation modeling. A concern raised over and over again, Assessment |
Reputation - wink wink, same thing when it come to coding it. Word
smithing does not solve implementation issues.
I
tThis update resolves that confusion. It defines
additional, semantic
labels for the two values, clarifies their nature and
specifies their
relationship. More specifically, it clarifies that the
identifier
intended for delivery to the assessor --
Steve Atkins wrote:
Given that the RHS of i= is either identical or a subdomain of d= it's
nonsensical
to consider i= more stable than d=, as i= must change if d= does.
In fact, other than the right-hand root of the i= string which must match the
d=
string, nothing in the i= value must
On Jun 16, 2009, at 2:35 PM, Michael Thomas wrote:
1) People saying that d= is THE IDENTIFIER are overloading the
value: d= a routing
label to a particular DNS subtree. Whether it has anything to do
with THE
IDENTIFIER is purely coincidental. The assumption that these two
On Jun 16, 2009, at 2:35 PM, Michael Thomas wrote:
There are a few points that seem to be lost in all of this:
1) People saying that d= is THE IDENTIFIER are overloading the
value: d= a routing label to a particular DNS subtree. Whether it
has anything to do with THE IDENTIFIER is
Dave CROCKER wrote:
Steve Atkins wrote:
Given that the RHS of i= is either identical or a subdomain of d= it's
nonsensical
to consider i= more stable than d=, as i= must change if d= does.
In fact, other than the right-hand root of the i= string which must match the
d=
string,
At 14:35 16-06-2009, Michael Thomas wrote:
1) People saying that d= is THE IDENTIFIER are overloading the
value: d= a routing
label to a particular DNS subtree. Whether it has anything to do with THE
IDENTIFIER is purely coincidental. The assumption that these
two functions are
On Tue, 16 Jun 2009 14:53:20 -0700 Murray S. Kucherawy
m...@cloudmark.com wrote:
...
The intent here, I believe, is to specify that d= is mandatory output of
a DKIM verifier module. i= (and everything else, frankly) is optional.
...
OK, so now I guess I'm confused. My understanding is that
OK, so now I guess I'm confused. My understanding is that if i= isn't
specified it takes the value of d=, so I'm not clear how it can be
undefined?
Maybe the wording of the errata draft could be improved (I'll propose new text
shortly if I can), but here's my understanding:
I believe
Murray S. Kucherawy wrote:
OK, so now I guess I'm confused. My understanding is that if i= isn't
specified it takes the value of d=, so I'm not clear how it can be
undefined?
Maybe the wording of the errata draft could be improved (I'll propose new
text shortly if I can), but here's
Jim Fenton wrote:
Dave has proposed a change to the rfc4871-errata draft in response to a
concern from the IESG. Can you clarify what concern the IESG has this
is attempting to address? I'll repeat my original question below since
you may have missed it.
It's attempting to address Cullen's
pasi.ero...@nokia.com wrote:
Jim Fenton wrote:
Dave has proposed a change to the rfc4871-errata draft in response to a
concern from the IESG. Can you clarify what concern the IESG has this
is attempting to address? I'll repeat my original question below since
you may have missed it.
Jim Fenton wrote:
I do have a problem with the last paragraph:
tFor signers and assessors that have been using the i= tag for
reputation assessment a software change to using the d= tag is
intended.
/t
and some of the text in the preceding paragraph because it
Will somebody please tell the editor that this still violates our charter
since reputation is out of scope?
Thank you.
Mike
Dave CROCKER wrote:
Jim Fenton wrote:
I do have a problem with the last paragraph:
tFor signers and assessors that have been using the i= tag for
Wietse Venema wrote:
+0.99
This clarifies what is the primary identifier that signers
intend to send to assessors.
If it helps to avoid stepping on sensitive toes, you could drop
the last sentence, but I can live with it.
+1 (rounding up)
And, by the way, I'm speaking as operator of a
Dave CROCKER wrote:
Jim Fenton wrote:
Can you clarify what IESG concern this is
attempting to address?
Frankly, for that level of question, I suggest you direct it to our
area director. That will be far more efficient than my attempting to
channel him and the rest of the IESG.
(sorry...I clicked the HTML button on the last try and my own PDA was
having problems with it)
Dave CROCKER wrote:
Jim Fenton wrote:
Can you clarify what IESG concern this is attempting to address?
Frankly, for that level of question, I suggest you direct it to our
area director. That
Folks,
In reviewing the errata (Update) draft, the IESG expressed concern that a
reader
could miss that there is a potential for software changes due to the change in
the specification. Indeed, some IESG readers and others did believe there was
no software change needed.
To clarify things,
This text inappropriately makes a normative requirement on reputation
systems. Reputation
systems are explicitly outside of the scope of our charter. As well they
should be as there
has been no discussion about reputation systems may or may not find
useful, let alone
require, from DKIM.
Proposed text:
tThis currently leaves signers and assessors with the potential for
making different interpretations between the two identifiers and may
lead to interoperability problems. A signer could intend one to be
used for reputation, and have a
Dave CROCKER:
Proposed text:
tThis currently leaves signers and assessors with the potential for
making different interpretations between the two identifiers and may
lead to interoperability problems. A signer could intend one to be
used for reputation, and
On Jun 11, 2009, at 11:50 PM, Dave CROCKER wrote:
Existing Introduction text:
This currently leaves signers and assessors with the potential
for having differing -- and therefore non-interoperable --
interpretations of how DKIM operates.
This update resolves this confusion. It
Wietse Venema wrote:
If it helps to avoid stepping on sensitive toes, you could drop
the last sentence, but I can live with it.
I'm pretty sure that the toe compression problem is inseparable from breathing
and certainly is joined at the hip with posting any email at all.
What appeals to me
Can you clarify what IESG concern this is attempting to address? I
looked at the IESG evaluation record for the draft
(https://datatracker.ietf.org/idtracker/ballot/3084/) and didn't see
anything that this change would address, except possibly Cullen's
comment that he asked three developers what
Jim Fenton wrote:
Can you clarify what IESG concern this is attempting to address?
Frankly, for that level of question, I suggest you direct it to our area
director. That will be far more efficient than my attempting to channel him
and
the rest of the IESG.
d/
--
Dave Crocker
45 matches
Mail list logo
