On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKER d...@dcrocker.net wrote:
Although some folk have done a +1 for one (or another) removal, I'd like to
get
a round of explicit reactions to the specific idea of removing /both/.
+1
--
Jeff Macdonald
Ayer, MA
On 10/15/2010 10:28 AM, Jeff Macdonald wrote:
On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote:
Although some folk have done a +1 for one (or another) removal, I'd like to
get
a round of explicit reactions to the specific idea of removing /both/.
+1
Folks,
The
On 10/15/2010 08:28 AM, Dave CROCKER wrote:
On 10/15/2010 10:28 AM, Jeff Macdonald wrote:
On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote:
Although some folk have done a +1 for one (or another) removal, I'd like to
get
a round of explicit reactions to the specific
I'd like to ask a procedural question of the chairs: Dave killfile's
many participants, therefore any consensus he sees will merely reflect
the echo chamber of his own making.
So I strongly object on procedural grounds for authors who kill file
people in general, and for those asking for
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Friday, October 15, 2010 10:17 AM
To: IETF DKIM WG
Cc: Barry Leiba
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
So I
On Fri, Oct 15, 2010 at 1:17 PM, Hector Santos hsan...@isdg.net wrote:
In fact, I have been looking at RFC 2026 Section 6.5.1 (a) as an
reason to appeal based on the principal key editors are knowingly
filtering input from WG participants. I know both Dave and Murray are
doing this and both
On 10/15/2010 10:32 AM, Barry Leiba wrote:
I'd like to ask a procedural question of the chairs: Dave killfile's
many participants, therefore any consensus he sees will merely reflect
the echo chamber of his own making.
So I strongly object on procedural grounds for authors who kill file
I was threatened with legal action [...]
I understand why you posted this, but, please, let's not continue this
sort of discussion on the list.
Everyone, we're here to find consensus and develop specifications.
Let's no one attack anyone else; let's work on cooperating.
As a conference button
On 10/15/10 7:28 AM, Jeff Macdonald wrote:
On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote:
Although some folk have done a +1 for one (or another) removal, I'd like to
get
a round of explicit reactions to the specific idea of removing /both/.
+1
Given the lack of
Of Hector Santos
Sent: Friday, October 15, 2010 10:17 AM
To: IETF DKIM WG
Cc: Barry Leiba
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
So I strongly object on procedural grounds for authors who kill file
people in general, and for those asking for consensus in particular
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Jim Fenton
Sent: Friday, October 15, 2010 10:25 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
Given the lack
On 10/15/2010 1:32 PM, Barry Leiba wrote:
Dave killfile's
many participants, therefore any consensus he sees will merely reflect
the echo chamber of his own making.
So I strongly object on procedural grounds
...
Mike, you needn't object unless the chairs put people in our
kill-files,
On 15/10/10 18:32, Barry Leiba wrote:
I'd like to ask a procedural question of the chairs: Dave killfile's
many participants, therefore any consensus he sees will merely reflect
the echo chamber of his own making.
So I strongly object on procedural grounds for authors who kill file
people
On 10/15/2010 11:19 AM, Dave CROCKER wrote:
On 10/15/2010 1:32 PM, Barry Leiba wrote:
Dave killfile's
many participants, therefore any consensus he sees will merely reflect
the echo chamber of his own making.
So I strongly object on procedural grounds
...
Mike, you needn't object
On 10/15/2010 10:45 AM, Stephen Farrell wrote:
In this case, I don't recollect an objection, so thus far, it seems
to me that Dave's correct on this one. I think its perfectly fine
for an editor to try to close off things that seem to have a clear
consensus like this.
Stephen -- the issue
On 15/10/10 19:48, Michael Thomas wrote:
On 10/15/2010 10:45 AM, Stephen Farrell wrote:
In this case, I don't recollect an objection, so thus far, it seems
to me that Dave's correct on this one. I think its perfectly fine
for an editor to try to close off things that seem to have a clear
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference to its role as input to
DKIM.
At the time DKIM was developed, worrying
Even though I supported the addition of wording on how to improve the
compatibility with DomainKeys records, I would support removing the new
proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to
ask the question: Is it still worth changing that section into a WARNING
for
On 10/14/2010 9:05 AM, Tony Hansen wrote:
Is it still worth changing that section into a WARNING
for people upgrading from DomainKeys, saying to make darn sure that they
REMOVE g=; in their old DNS records because of interoperability issues?
So the question becomes: if we remove the
On Thu, Oct 14, 2010 at 8:09 AM, Dave CROCKER d...@dcrocker.net wrote:
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference
agreed
On Oct 14, 2010, at 8:09 AM, Dave CROCKER wrote:
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference to its
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Thursday, October 14, 2010 5:10 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/13/2010 1:52 PM, Jim
On 10/14/10 6:30 AM, Dave CROCKER wrote:
On 10/14/2010 9:05 AM, Tony Hansen wrote:
Is it still worth changing that section into a WARNING
for people upgrading from DomainKeys, saying to make darn sure that they
REMOVE g=; in their old DNS records because of interoperability issues?
So
On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen t...@att.com wrote:
Even though I supported the addition of wording on how to improve the
compatibility with DomainKeys records, I would support removing the new
proposed section 3.6.1.1 for the reasons Dave brings up. But I'd like to
ask the
On 10/14/2010 11:54 AM, Barry Leiba wrote:
On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansent...@att.com wrote:
Even though I supported the addition of wording on how to improve the
compatibility with DomainKeys records, I would support removing the new
proposed section 3.6.1.1 for the reasons
On Oct 14, 2010, at 5:09 AM, Dave CROCKER wrote:
On 10/13/2010 1:52 PM, Jim Fenton wrote:
I propose removing section 3.6.1.1 in its entirety.
Not only do I support this, but I think we can remove all references to
DomainKeys, except for the obvious historical reference to its role as input
Barry, there are crossing questions.
This question came up in response to removing 3.6.1.1 totally separate
from the question of removing g= altogether.
If we remove 3.6.1.1 without removing g= altogether, the question below
becomes pertinent.
If we remove g= altogether, then we can remove
No, that doesn't solve the problem for all of the implementations
that are out there now that implement 4871. Removing g= is only going
to make the situation even worse because you've now taken away the
documentation.
I wouldn't be opposed to moving it to an appendix of deprecated features,
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Dave CROCKER
Sent: Thursday, October 14, 2010 3:33 PM
To: Tony Hansen
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
Although
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of John R. Levine
Sent: Thursday, October 14, 2010 3:31 PM
To: Barry Leiba
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/14/10 3:30 PM, John R. Levine wrote:
No, that doesn't solve the problem for all of the implementations
that are out there now that implement 4871. Removing g= is only going
to make the situation even worse because you've now taken away the
documentation.
I wouldn't be opposed to
if for nothing else to ensure that some future DKIM++ doesn't
inadvertently reuse g= to mean something else.
Isn't that what the IANA registry is there to prevent?
I dunno. What does IANA do in cases like these?
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for
On Oct 14, 2010, at 4:44 PM, John R. Levine wrote:
if for nothing else to ensure that some future DKIM++ doesn't
inadvertently reuse g= to mean something else.
Isn't that what the IANA registry is there to prevent?
I dunno. What does IANA do in cases like these?
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Steve Atkins
Sent: Thursday, October 14, 2010 5:00 PM
To: DKIM List
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
http://www.iana.org/assignments
On 10/14/2010 6:30 PM, John R. Levine wrote:
I wouldn't be opposed to moving it to an appendix of deprecated features,
if for nothing else to ensure that some future DKIM++ doesn't
inadvertently reuse g= to mean something else.
Since this particular feature is apparently used in about .0007%
If a v= value is not found at the beginning of the DKIM key record,
the key record MAY be interpreted as for DomainKeys [RFC4870]. The
definition given here is upwardly compatible with what is used for
DomainKeys, with the exception of the g= value. In a DomainKeys
key
If a v= value is not found at the beginning of the DKIM key record,
the key record MAY be interpreted as for DomainKeys [RFC4870]. The
definition given here is upwardly compatible with what is used for
DomainKeys, with the exception of the g= value. In a DomainKeys
key
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Barry Leiba
Sent: Wednesday, October 13, 2010 3:46 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
Everyone, please weigh
At 13:03 13-10-10, Barry Leiba wrote:
To avoid second-guessing in a security context, and because
DomainKeys is an obsolete protocol, DKIM verifiers MUST
interpret this situation in DKIM terms, matching only
empty i= values.
Changing the g= definition takes advancement
This is a comment on the new section 3.6.1.1, Compatibility Note for
DomainKeys, that suggests a different interpretation of the g= tag in
the key record if the v= value is not present at the beginning of the
record. The section says:
If a v= value is not found at the beginning of the
40 matches
Mail list logo
