Douglas Otis wrote:
1) Why?
There is use in specifying an API here. Every other protocol we've
named so far as examples have an API, whether de facto from lots of
experience, or implicit from the spec that defines it the protocol,
or something actually explicit defining the API.
On Jun 18, 2009, at 11:18 AM, hector wrote:
Douglas Otis wrote:
1) Why?
There is use in specifying an API here. Every other protocol
we've named so far as examples have an API, whether de facto from
lots of experience, or implicit from the spec that defines it the
protocol, or
Douglas Otis wrote:
On Jun 18, 2009, at 11:18 AM, hector wrote:
Douglas Otis wrote:
1) Why?
There is use in specifying an API here. Every other protocol
we've named so far as examples have an API, whether de facto from
lots of experience, or implicit from the spec that defines it
Douglas Otis wrote:
On Jun 18, 2009, at 11:18 AM, hector wrote:
This is why I as seeking an answer to why just d= and not anything
else. What it for a reputation system?
The response from a closed group of large email providers regarding
how they would like to have their reputation
] Modified Introduction text forrfc4871-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
MH Michael Hammer (5304) wrote:
+1
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
Hmmm. Noting two quick +1s to Murray's text and in the interest of still
trying
to bring this quick errata/update effort to a close, I'm inclined to suggest
adding his explanatory text to the
] Modified Introduction text forrfc4871-errata (resend)
Importance: High
MH Michael Hammer (5304) wrote:
+1
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
Hmmm. Noting two quick +1s to Murray's text and in the interest of still trying
to bring this quick errata/update effort
On Wed, Jun 17, 2009 at 9:07 PM, bill.ox...@cox.com wrote:
+1
+1
tFor signers and verifiers that have been using the i= tag as the
primary value that is delivered to the assessor, a software change to
using the d= tag is intended.
/t
s/intended/required/
API Definition? The socket example? Come on.
BTW, What is the definition of an Application Programming Interface
and what portion of DKIM is like an API definition.
This is incomprehensible, overdone to get some simple concept across
that only needs 1 or 2 paragraphs. Dave, these paragraphs
On Jun 17, 2009, at 8:08 AM, Dave CROCKER wrote:
So, here's a suggested merging of the two:
This 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
BTW, What is the definition of an Application Programming Interface
and what portion of DKIM is like an API definition.
I'm quite comfortable with drawing an implicit you must be this tall line and
assuming someone reading this, i.e. an implementer (e.g. YOU), will know what
an API is.
Or
So, here's a suggested merging of the two:
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
If you going to this level, you need to be more specific with software
engineering terminologies and how it applies to SMTP. Murray's API is
not going to be same as MY API or that guys API and it may not be just
in C or C++, but in multiple of languages, and the API be COM
interface, a .NET
Any reputation assessment system should not:
1) limit what is to be assessed.
The proposed text does not put any limits on what gets assessed. If an
assessor wants more information, it is free to use a verifier that provides
more information.
2) allow inclusion of un-assessed information
Murry,
How else can this be said?
Think SMTP and think how a SMTP system will provide the process
environment variables to either embedded filtering system or external
SMTP filtering system.
Most SMTP servers with an ACL or similar concept, including SendMail
with its mfilters, our ours with
Murray S. Kucherawy wrote:
All the errata is saying is that all DKIM APIs must return, at a
minimum, the d= and the evaluation result. There are no other
limits imposed.
The concern I have is that an SMTP vendor may erroneous model his
Assessor hook by recording two data points on the
On Jun 17, 2009, at 2:24 PM, Murray S. Kucherawy wrote:
You have generalize ASSESSORS to have two minimum inputs:
BOOLEAN (DKIM verification result)
STRING (DKIM D= value)
Correct.
1) Why?
There is use in specifying an API here. Every other protocol we've
named so far as
Suresh Ramasubramanian wrote:
tFor signers and verifiers that have been using the i= tag as the
primary value that is delivered to the assessor, a software change to
using the d= tag is intended.
/t
s/intended/required/ possibly?
while you are right,
18 matches
Mail list logo
