[SPF v1 Draft] Last chance before I submit...

Thank you all for your input.  Here is some comments on the last chance 
input:
1) SHOULD ... -all language
I'm sorry this is still rearing it's head.  From RFC 2119:

        3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
           may exist valid reasons in particular circumstances to ignore a
           particular item, but the full implications must be understood and
           carefully weighed before choosing a different course.

So there is no obligation to publish with "-all", so long as you have 
decided not to.

2) Modifiers: Duplicate and Ordered
Okay.  Here's the final -- I'm going to change the wording to make it 
clear that:
    - Defined modifiers cannot appear more than once, and if so, it is 
a PermError.
    - Unrecognized modifiers are to be ignored, even if they appear 
multiple times.
    - Modifiers are position independent.

For the record, I think these would be bad semantics for a final 
standard.  The reason is that it makes it hard to write a stable parser 
in the face of extensible modifiers.  This is why I concocted the 
Global/Positional/Singular/Plural classification scheme in the Sender 
ID protocol drafts.
However, for this experimental draft, since we really don't know what 
we are going to do with modifiers in the future, and we will expect 
people to re-write their parsers, I'll allow this since it seems to be 
the common view.
As for William's examples:  Yes, both pairs are exactly the same 
semantically, and the redirect modifier will never be used due to the 
-all directive.

3) Direct HELO check
Yes, it is a little late to revisit this one.  It has been hashed out 
quite a bit.  However, I will note that nothing in the spec precludes 
software from using the check_host() function on the HELO domain.  
Furthermore, since the null reverse path rule causes publishes to have 
SPF records for their HELO domains, such a check will not violate any 
assumptions that a publisher would have.  (I will not go into all the 
cases here, but will in another thread if people want to explore this 
one again.)

4) Implementing check_host()
I have taken the recommendation to clean up the wording of how an 
implementor may code the check_host() function.
However, I will not be including language that puts prohibitions on 
other uses of SPF records or the check_host() function.  Standards 
themselves are open:  You are free to put to use the telnet protocol, 
or MX records, or ICMP messages to any use you want, open, proprietary 
or otherwise.  Of course, you may violate excepted usage or fail to be 
compliant with the standard if you do.  You are free to stream audio at 
my computer encoded in clever ICMP PING packets, but my machine 
probably won't take it, and if there are too many, my ISP will firewall 
you.  The SPF records described in this draft only authorize use of 
domain names in the Mail From identity.  You can use it to check Header 
From, but it may not work.  Similarly, you can send mail to the domain 
listed in my URL, but that may not work either.
        - Mark