On 5/11/09 7:51 AM, Murray S. Kucherawy wrote:
On Sun, 10 May 2009, Dave CROCKER wrote:
For l=, a MAY for signers produces a MUST for verifiers.
Why is that necessarily the case?
Right. l= may simply be ignored and the signature considered invalid if
the message is
On 5/9/09 2:01 AM, John Levine wrote:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
I like deprecating useless stuff,
Eliot Lear wrote:
On 5/9/09 2:01 AM, John Levine wrote:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
I like
On 5/10/09 8:28 AM, Dave CROCKER wrote:
Deprecating what is non-essential facilitates adoption. You can't
facilitate that adoption if you wait until there is more adoption.
I agree. Understanding what's non-essential requires time and
consideration of use cases, one of which I have
On Sun, May 10, 2009 at 12:41 PM, Eliot Lear l...@cisco.com wrote:
I agree. Understanding what's non-essential requires time and
consideration of use cases, one of which I have mentioned. We can talk
about tags in that context, but I would like mailing list manager
developers to be part of
Eliot Lear wrote:
On 5/10/09 8:28 AM, Dave CROCKER wrote:
Deprecating what is non-essential facilitates adoption. You can't
facilitate that adoption if you wait until there is more adoption.
I agree. Understanding what's non-essential requires time and
consideration of use cases, one of
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Wietse Venema
I too am in favor of less complexity. We could start by
keeping only the attributes that must always be sent.
+1
Ellen
Murray S. Kucherawy wrote:
For the sake of trying to find some compromise, can we do what we did
with the AUID/SDID debate and indicate which tags an implementation MUST
support and which ones it MAY support?
Always a reasonable goal. But what makes that sort of exercise challenging,
On Sun, 10 May 2009, Dave CROCKER wrote:
For example, saying MAY on l= could mean that a signer might choose to
implementer and a validator might not. Hence, no interoperability.
In the case of z=, for example, a verifier electing not to implement
would simply ignore the tag.
If the use of
On Sat, 9 May 2009, Dave CROCKER wrote:
The simpler a spec is, the easier it is to develop, test and
operate, and the easier it is to explain to others.
Deprecating what is non-essential facilitates adoption. You can't
facilitate that adoption if you wait until there is more
Murray S. Kucherawy wrote:
Given this, I'd say we should list l= as a MAY, and advise signers
that a verifier might not care that you said l=, be that simply
because l= wasn't implemented at the verifier, or perhaps it was
implemented but the verifier had a strict policy on its use and
John Levine wrote:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
So you have a itemized list of what you consider useless stuff?
John Levine:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
I too am in favor of less complexity. We could start by
keeping only
On May 9, 2009, at 8:10 AM, Hector Santos wrote:
John Levine wrote:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
So you have
Suresh Ramasubramanian wrote:
And after that I'd
suggest devoting some energy to an implementation white paper,
Comments on the Deployment draft
http://dkim.org/ietf-dkim.htm#deployment
are eagerly sought!
and
possibly another interoperability workshop to make sure various
On May 9, 2009, at 10:07 AM, Dave CROCKER wrote:
Suresh Ramasubramanian wrote:
And after that I'd
suggest devoting some energy to an implementation white paper,
Comments on the Deployment draft
http://dkim.org/ietf-dkim.htm#deployment
are eagerly sought!
and
possibly another
Wietse Venema wrote:
John Levine:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
I too am in favor of less
On Sun, May 10, 2009 at 12:22 AM, Michael Thomas m...@mtcc.com wrote:
This is exactly why reopening this at this point is a stupid and
dangerous idea. There is nothing to be gained by this kind of
discussion except mass confusion, and making perfectly compliant
deployments broken.
You can
Michael Thomas wrote:
Wietse Venema wrote:
John Levine:
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
I too am
On 5/8/09 7:07 AM, Dave CROCKER wrote:
I hadn't noticed anyone suggesting doing anything that cycled the
specification
at Proposed. (The requirement placed on the Errata is different than we're
discussing for the -bis effort.)
Have you heard otherwise?
That would be me. Refer to
Eliot Lear wrote:
On 5/8/09 7:07 AM, Dave CROCKER wrote:
I hadn't noticed anyone suggesting doing anything that cycled the
specification
at Proposed. (The requirement placed on the Errata is different than we're
discussing for the -bis effort.)
Have you heard otherwise?
That would be
Dave CROCKER wrote:
Eliot Lear wrote:
On 5/8/09 7:07 AM, Dave CROCKER wrote:
I hadn't noticed anyone suggesting doing anything that cycled the
specification
at Proposed. (The requirement placed on the Errata is different than we're
discussing for the -bis effort.)
Have you heard
Dave CROCKER wrote:
Referring back to my message, I'm advocating that if we do anything, we
move to Draft Standard, and advocating that we not do another spin at
Proposed Standard. So are we agreeing?
I hadn't noticed anyone suggesting doing anything that cycled the
specification at
So let me try summarise and ask a question.
I don't think I've seen anyone who wants to do more than
just roll up the existing errata into a bis document, possibly
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other
On May 8, 2009, at 11:38 AM, Stephen Farrell wrote:
If so, then it may be that we do have consensus to produce a 4871bis
that rolls up the errata and makes editorial clarifications that
garner consensus along the way but no more.
Does that sound about right?
Yes.
-Doug
Is it too much to insist that anything we do here be reflected in the
_charter_
so that there is no misunderstanding? As it stands, there is nothing in our
charter that says anything about any of this.
Mike
Stephen Farrell wrote:
So let me try summarise and ask a question.
I don't
On May 8, 2009, at 11:38 AM, Stephen Farrell wrote:
So let me try summarise and ask a question.
I don't think I've seen anyone who wants to do more than
just roll up the existing errata into a bis document, possibly
with some editorial changes I guess. I've not seen anyone
suggest that we
On Sat, May 9, 2009 at 3:39 AM, Steve Atkins st...@wordtothewise.com wrote:
I suggest we remove some of the features that
complicate deployment and/or add no value, and
I think a -bis draft is a reasonable point in the process
to do so.
Trimming the fat would be one way to go, yes. And
with some editorial changes I guess. I've not seen anyone
suggest that we add features or remove a raft of features
or make other substantial changes.
I'm with Steve, I'd like to deprecate the useless stuff.
R's,
John
___
NOTE WELL: This list operates
Dave CROCKER wrote:
Jim,
Jim Fenton wrote:
Having just reviewed yet another document referring to recent activity
by the Internet Engineering Task Force (IETF) to create protocol
standards around SPF and DKIM, I am reminded how little the community
outside IETF grasps the difference between
Jim Fenton wrote:
I'm saying (recognizing this is well outside the scope of the working
group) that IETF has a problem in that it publishes informational,
experimental, and historic RFCs and many people outside IETF immediately
think anything with an RFC number is an IETF standard. That
Jim,
Jim Fenton wrote:
Having just reviewed yet another document referring to recent activity
by the Internet Engineering Task Force (IETF) to create protocol
standards around SPF and DKIM, I am reminded how little the community
outside IETF grasps the difference between Informational,
Dave,
Although it seems that I'm on the other side of the issue from Jim, I'm
don't think the below is quite fair.
On 5/6/09 5:50 PM, Dave CROCKER wrote:
And just to keep things real, can you cite some examples of the effect you are
concerned about?
If we accept the existing dogma that
Eliot,
Eliot Lear wrote:
Although it seems that I'm on the other side of the issue from Jim, I'm
don't think the below is quite fair.
And just to keep things real, can you cite some examples of the effect
you are concerned about?
If we accept the existing dogma that draft indicates
On May 6, 2009, at 8:50 AM, Dave CROCKER wrote:
If, indeed, a feature is unused or problematic, then how will
dropping it hurt adoption? A simpler specification typically aids
adoption, rather than hurting it.
And just to keep things real, can you cite some examples of the
effect
I'd like to break these into two points:
1. On whether to do rfc4871bis at all
I tend to agree with Tony that we should do a -bis to clean up the
errata. If scoped as such it should be a very brief operation, taking
no more than 6 months.
2. On whether to move to draft standard
While I
On Mon, May 4, 2009 at 1:58 PM, Eliot Lear l...@cisco.com wrote:
I'd like to break these into two points:
1. On whether to do rfc4871bis at all
-bis - yes. Definitely.
2. On whether to move to draft standard
While I was initially in favor of this, I am now uncomfortable doing so,
based
1. On whether to do rfc4871bis at all
I tend to agree with Tony that we should do a -bis to clean up the
errata. If scoped as such it should be a very brief operation, taking
no more than 6 months.
Agreed, the world needs a description of DKIM and its warts in one place.
2. On whether to
Tony Hansen wrote:
As to why bother, with 16 errata to pore through, I feel that it is much
better to have one place to look for the technical spec instead of 17
documents.
+1
Let's get bissy.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
Eliot Lear wrote:
I'd like to break these into two points:
1. On whether to do rfc4871bis at all
I tend to agree with Tony that we should do a -bis to clean up the
errata. If scoped as such it should be a very brief operation, taking
no more than 6 months.
If we do this, we need to
On 5/4/09 9:17 PM, Jeff Macdonald wrote:
2. On whether to move to draft standard
While I was initially in favor of this, I am now uncomfortable doing
so,
based on the lengthy debate we just concluded about errata. To me the
Qualified approval based on consensus gained in the -bis draft.
On Mon, May 04, 2009 at 09:26:15PM +0200, Eliot Lear wrote:
On 5/4/09 9:17 PM, Jeff Macdonald wrote:
2. On whether to move to draft standard
While I was initially in favor of this, I am now uncomfortable
doing so,
based on the lengthy debate we just concluded about errata. To me the
On Mon, May 04, 2009 at 03:53:11PM +0530, Suresh Ramasubramanian wrote:
On Mon, May 4, 2009 at 1:58 PM, Eliot Lear l...@cisco.com wrote:
I'd like to break these into two points:
1. On whether to do rfc4871bis at all
-bis - yes. Definitely.
2. On whether to move to draft standard
While I
Tony Hansen wrote:
I'm certainly ready to move forward with 4871bis. Yes, the protocol is
ready to go to Draft Standard. No, we do not need another cycle at
Proposed Standard. I think there's enough energy in the group to get
4871bis through.
As to why bother, with 16 errata to pore
Procedure point:
Maybe somebody can clarify whether you can roll errata from a PS and
go directly to draft. I gather from Eliot that you can't (?).
My reading of things:
The 15 *real* errata won't stop anything. They're really minor
changes, and could be rolled into an updated 4871 that goes
Barry Leiba wrote:
So the questions are whether DKIM base, with the recent update, would
be ready by then, and whether we care to do it. Mike and John, in a
rare display of agreement, have both opined that no one cares about
it. There is that thought: the IETF three-stage standards track is
This is the promised seed for 4871bis discussion. Is the group ready
to move ahead with that? Is the DKIM signing protocol ready to go to
Draft Standard? Is there an update needed, with another cycle at
Proposed Standard? Is there energy in the group to follow a 4871bis
effort through?
Please
Barry Leiba wrote:
This is the promised seed for 4871bis discussion. Is the group ready
to move ahead with that? Is the DKIM signing protocol ready to go to
Draft Standard? Is there an update needed, with another cycle at
Proposed Standard? Is there energy in the group to follow a 4871bis
I'm certainly ready to move forward with 4871bis. Yes, the protocol is
ready to go to Draft Standard. No, we do not need another cycle at
Proposed Standard. I think there's enough energy in the group to get
4871bis through.
As to why bother, with 16 errata to pore through, I feel that it is much
49 matches
Mail list logo
