Re: [ietf-dkim] Issue: Operations Note in 6.4 redundant and should be removed

2011-04-29 Thread Hector Santos
Scott Kitterman wrote:

> Looking at 6.5, and then looking back at 6.4 (Determine the Header Fields to 
> Sign), it seems to me that the "INFORMATIVE OPERATIONS NOTE" in 6.4 attempts 
> to describe the considerations that are normatively described in 6.5.  It's 
> redundant and ought to be deleted.  Given what's in 6.5 now, it's just a 
> potential source of confusion.

I see your point.

I think the note saying about "not-obvious" is generally true, but we
do have a pretty strong mail system insight to have a top DKIM strategy.

For me, dependent of DKIM, the end game in a heterogeneous mail 
network was always about WYSIWYG and the ability to reply back, so:

   - end to end persistency expectation, i.e. WYSIWYG, and
   - transport (network controls) persistency expectation.

The note does reflect this in show many words and in mixed strategies,
but there should be one top DKIM strategy that offers the best
technical and DKIM results.

If that can be stated in 6.5, I agree the 6.4 note would become redundant.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


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


Re: [ietf-dkim] Issue: Operations Note in 6.4 redundant and should be removed

2011-04-29 Thread Scott Kitterman
On Friday, April 29, 2011 09:22:15 AM Hector Santos wrote:
> I think the rev8 version of section 6.5 is much better, but I have a
> change proposal with the background reasoning listed below it:
> 
...

I've had no time recently, so I've been attempting to avoid looking at last 
call messages since I didn't have time to follow it closely.  In this case I 
failed

Looking at 6.5, and then looking back at 6.4 (Determine the Header Fields to 
Sign), it seems to me that the "INFORMATIVE OPERATIONS NOTE" in 6.4 attempts 
to describe the considerations that are normatively described in 6.5.  It's 
redundant and ought to be deleted.  Given what's in 6.5 now, it's just a 
potential source of confusion.

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