Hi, Jim,
I just read the draft and feels not sure about some point:
In the last paragraph of section 1, you said:
In order to permit useful reputation accrual, the value of the
reputation tag will typically need to be stable over a relatively
long period of time. The use of a tag which
Siegel, Ellen:
I for one would prefer a straight up +1/-1 vote on the errata draft as
it stands.
+1
I do agree that it would be a Good Thing to roll this and all the
other errata into a -bis spec draft, but think that it would be
better to nail down what we have as errata first
On Fri, Feb 13, 2009 at 6:32 PM, Wietse Venema wie...@porcupine.org wrote:
Siegel, Ellen:
+1
+1.
Wietse
+1
--srs
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
would any of the people who are saying +1 please answer the following
two questions:
1. Beyond confusion surround i=, what is the interoperability problem?
2. Is it possible to correct the problem without additional text?
A reference to a previous message that answers these questions would be
Folks,
Please hold off on +1's etc until Barry I respond to Dave's
request for a WGLC. If and when we do WGLC then you'll need
to resend anyway, so there's no need now.
S.
___
NOTE WELL: This list operates according to
On Thu, Feb 12, 2009 at 05:38:34PM -0500, Siegel, Ellen wrote:
... The Signer MAY choose to use the same namespace for its UAIDs as
its
users' email addresses, or MAY choose other means of representing its
users. However, the signer SHOULD use the same UAID for each message
intended
On Fri, 13 Feb 2009, Jeff Macdonald wrote:
In other words, I think the intent is that messages using the same
UAID MUST be intended to be evaluated as sharing the same sphere of
responsibility (this is a mandate on the sender's usage, not on the
receiver's interpretation); senders SHOULD thus
Sean Shen wrote:
Hi, Jim,
I just read the draft and feels not sure about some point:
In the last paragraph of section 1, you said:
In order to permit useful reputation accrual, the value of the
reputation tag will typically need to be stable over a relatively
long period of time.
Stephen, Pasi, and I have been considering the status and direction of the DKIM
working group, and we think some clarification and procedural steering is
important right now. Here are some thoughts of the chairs, Stephen and me, on
where we are and what we need to do next.
Recent discussion
Barry,
Sorry for being so confused, but I'm hoping you can clear up some questions:
DKIM Chair wrote:
Recent discussion has brought up the point that, while we had consensus in
4871
about i=,
Recent discussion also brought up the point that this assertion was factually
incorrect and that
On Feb 13, 2009, at 3:33 PM, Ellen Siegel wrote:
Can you explain why you think this makes it impossible to use i= in
an arbitrary way? I don't see that that usage is excluded. If it's
not intended to be stable, there is no constraint at all except that
it can't use an identical
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry,
I think that we're dealing with a false dichotomy between a straw man
and beating a dead horse with a red herring.
4871 is in my opinion as an author clear about i=. You have but to
read it and the informative notes. One might think it's
Therefore, the first thing we have to do, right now, is take care of the
errata, with clarification, but not change, on the i= issue.
Dave's draft clarifies the meaning and use of i=. It's time for a last
call on it.
R's,
John
___
NOTE WELL: This
At 15:58 13-02-2009, Murray S. Kucherawy wrote:
We SHOULD NOT (in 2119 terms) make any changes to the base spec, which is
followed by a growing deployed base, via erratum or a full revision in a
way which establishes any new constraints.
A base specification generally takes a minimalist approach
Responding to Dave's, Doug's, and John's replies (I'll get to Jon's later)...
Dave says...
Recent discussion has brought up the point that, while we had consensus in
4871 about i=,
Recent discussion also brought up the point that this assertion was factually
incorrect and that there is no
Jon says...
4871 is in my opinion as an author clear about i=. You have but to read it and
the informative notes. One might think it's amorphous, but it's at least an
explicit amorphousness. It survived a rough consensus, at least implicitly. I
will summarize 4871 as signers can do whatever
DKIM Chair wrote:
Dave's draft clarifies the meaning and use of i=. It's time for a last
call on it.
Stephen was planning to do that on Monday.
thanks for clarifying that.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
17 matches
Mail list logo
