Hello,
At 10:05 05-04-2006, [EMAIL PROTECTED] wrote:
Yes, the case indicates importance, much like bold/italic or underline,
not meaning
I believe http://www.ietf.org/rfc/rfc2119.txt sums it.
Regards,
-sm
___
NOTE WELL: This list operates accordi
On Apr 5, 2006, at 9:36 AM, Dave Crocker wrote:
Arvel Hathcock wrote:
> The MUST NOT was there in the earlier proposal because the
association
> between p= and the headers was by hash values. This proposal
removes
> that, and MUST NOT is not needed. If we use "SHOULD NOT", we
need to
Arvel Hathcock wrote:
> the case of a should does not change its semantics.
> if the text specifies behavior, it is being normative.
Are you saying a 'SHOULD' and a 'should' have essentially the same meaning?
No.
I am saying that they have *exactly* the same meaning.
English does not di
Sent: Wednesday, April 05, 2006 12:50 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Alternative text for semantics of multiple
signatures
> the case of a should does not change its semantics.
>
> if the text specifies behavior, it is being normative.
Are you saying a '
> the case of a should does not change its semantics.
>
> if the text specifies behavior, it is being normative.
Are you saying a 'SHOULD' and a 'should' have essentially the same meaning?
--
Arvel
___
NOTE WELL: This list operates according to
htt
Arvel Hathcock wrote:
> The MUST NOT was there in the earlier proposal because the association
> between p= and the headers was by hash values. This proposal removes
> that, and MUST NOT is not needed. If we use "SHOULD NOT", we need to
> say when it is OK to do it anyway. Proposal: "To avo
> The MUST NOT was there in the earlier proposal because the association
> between p= and the headers was by hash values. This proposal removes
> that, and MUST NOT is not needed. If we use "SHOULD NOT", we need to
> say when it is OK to do it anyway. Proposal: "To avoid deleting
> information tha
I'm good with this.
-Dennis
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Michael Thomas
> Sent: Tuesday, April 04, 2006 3:09 PM
> To: Paul Hoffman
> Cc: ietf-dkim@mipassoc.org
> Subject: [ietf-dkim] Alterna
At 11:28 PM +0100 4/4/06, Stephen Farrell wrote:
Paul Hoffman wrote:
At 10:59 PM +0100 4/4/06, Stephen Farrell wrote:
If no-one wants to insist on signatures having to be sequential,
then this could be fairly easy!
Signatures have to be sequential if you sign them, given our
current rules fo
Paul Hoffman wrote:
At 3:10 PM -0700 4/4/06, Michael Thomas wrote:
I copied this from Paul's original. I'm good either way, though
SHOULD seems more appropriate now.
The MUST NOT was there in the earlier proposal because the association
between p= and the headers was by hash values. This pro
Paul Hoffman wrote:
At 10:59 PM +0100 4/4/06, Stephen Farrell wrote:
If no-one wants to insist on signatures having to be sequential,
then this could be fairly easy!
Signatures have to be sequential if you sign them, given our current
rules for signing and verifying h=.
Then I'm confused
At 3:10 PM -0700 4/4/06, Michael Thomas wrote:
Signers MUST NOT remove any DKIM-Signature headers from messages
they are signing, even if they know that the headers cannot be
verified.
Is MUST NOT ok there, as opposed to SHOULD NOT? I seem to recall someone
wanting to be able to re
Stephen Farrell wrote:
Paul Hoffman wrote:
At 1:09 PM -0700 4/4/06, Michael Thomas wrote:
When evaluating a message with multiple signatures, a receiver
SHOULD evaluate signatures independently and on their own merits.
Is that really a SHOULD? How could it be tested? Perhaps "shoul
At 10:59 PM +0100 4/4/06, Stephen Farrell wrote:
If no-one wants to insist on signatures having to be sequential,
then this could be fairly easy!
Signatures have to be sequential if you sign them, given our current
rules for signing and verifying h=. The question is whether or not we
care abo
Paul Hoffman wrote:
At 1:09 PM -0700 4/4/06, Michael Thomas wrote:
[transmogrified from Paul's original text]
Rationale:
Signers need a way to attach multiple signatures when transitioning from
one signature algorithm to another, when transitioning from one hash
algorithm to another, and eve
-dkim@mipassoc.org
Subject: [ietf-dkim] Alternative text for semantics of multiple
signatures
[transmogrified from Paul's original text]
> Rationale:
> Signers need a way to attach multiple signatures when transitioning
from
> one signature algorithm to another, when transitioning
At 1:09 PM -0700 4/4/06, Michael Thomas wrote:
[transmogrified from Paul's original text]
Rationale:
Signers need a way to attach multiple signatures when transitioning from
one signature algorithm to another, when transitioning from one hash
algorithm to another, and even from one protocol ver
[transmogrified from Paul's original text]
Rationale:
Signers need a way to attach multiple signatures when transitioning from
one signature algorithm to another, when transitioning from one hash
algorithm to another, and even from one protocol version to another.
Further, there are many scenari
18 matches
Mail list logo