ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

2009-06-17 13:34:00
Are you trying to say?

     DKIM_RESULT = DKIM_VERIFY(ENVELOPE,  PAYLOAD)
     FINAL_RESULT = DKIM_ASSESSOR(DKIM_RESULT,  DKIM_TAG_QUERY("D") )
<<-- minimum requirement?

I don't fully understand your notation, but I think what I'm saying is that a 
minimal DKIM implementation provides what's in parentheses on the second line.  
It might provide more, but to claim to be compliant (after approval of the 
errata document) it has to provide at least that much.

What does the verification process entail?

You've shown it in the first line above.

Think of another example, like the socket interface to TCP vs. the
TCP protocol itself.  There's what's going on in the protocol stack and
then there's what's going on in the C libraries we actually use.

How about higher layer wrappers and classes for sockets which have
different models, sync vs async for example? <g>

Also good examples: None of them offer you direct access to data in the TCP 
headers, for example.  They could, but they don't.  All you need as an 
application writer is the payload (if any) and a return status from an 
operation.  The internal bits are generally not your concern.  If you really 
want the internal stuff, you can switch to raw sockets or an API with more 
switches and knobs.

The libc function gethostbyname() is another example: you give it a hostname 
and it gives you back one or more IP addresses (or an error).  If you want more 
control over the query and the reply, switch to the res_*() functions.  If you 
want even more control over stuff like timeouts and the actual transport, use 
res_mkquery() and manage the sockets yourself.  The underlying protocol is the 
same in all cases.

(I could be wrong but for the sake of example, let's say:) POSIX specifies 
gethostbyname() will give you back what you want plus an error status in a 
global variable called h_errno.  Let's also say some implementation decides to 
do invisibly do DNSSEC, and for that implementation you get another global 
called h_dnssec that tells you whether or not the reply was secure.  Both the 
"standard" implementation and this one are POSIX-compliant, but this one has 
some extensions.  And maybe everyone desires that extension and installs this 
version of the resolver and uses it.  It may even become wildly popular, but 
the extension is "officially" not interoperable in terms of what the standard 
says.  The DKIM errata document, to me, simply declares a minimal interface 
that you MUST export in order to be able to say you are compliant.

I got that impression too when it was first put out.  But I think it
was
odd since implementators will do what is necessary to make whatever is
necessary.   Any API interface and I/O will be defined by the ASSESSOR.
It will define what is needed to do its work. The input is simple - RFC
2822 payload.   If you are saying the basic model for an accessor is

     BOOL DKIM_ASSESSOR(BOOL DKIM_RESULT,  STRING D_TAG_VALUE)

thats cool. But why limit yourself?

Nobody's saying you have to limit yourself.  On the contrary, what I believe 
the errata document is trying to do is specify clearly that you have to do at 
least X, but doesn't constrain you from doing more.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>