On Sun, 26 Mar 2006, geoffj wrote:
Frank Ellermann wrote:
Somebody posted
a short list with nits a few days ago here, made all sense -
purely editorial stuff.
This may have been my list, noticed, it seemed, only by Frank.
Sorry about that. And thank you very much for your suggestions and
proof-reading.
I will repeat it here, not because these nits are all that important, but
because the document itself is excellent and also because a couple of these
are a bit "political" and we don't at this stage want to get up anyone's nose
unnecessarily.
By the way, my take on:
When a mechanism is evaluated, one of three things can happen: it can
match, it cannot match, or it can throw an exception.
is to write <<it can not-match>>. I vaguely remember this being suggested
ages ago about when this awkward sentence first appeared. There was a time
when "can-not" was the spelling, so we might here be coining a useful new
word!
Geoff
And here is my "short list":
. I noted a couple of nits,
some of which are probably noted elsewhere (I didn't check), some not
relevant to AUTH48 and some
you won't agree with! My suggestions are within <<>>. Only one is really an
"error" as I see it, the solecism
on page 7.
[Page 6]
Treating "Neutral" more harshly than "None" will <<would>> discourage domain
owners from
testing the use of SPF records (see Section 9.1)
Added to page, as previous text was not syntax error, this change will require
approval of the council
[Page 7]
The domain believes the host is not authorized but
is not willing to make that strong of a statement.<<such a strong
statement>>
Similarly added as proposed change but will require approval of the council
[Page 8]
This is the same whether the TXT or SPF RR type is used.
<<SPF RR has not been introduced at this stage of doc>>
I modified the text to be:
This is the same whether the TXT or SPF RR type 99 (see
section 3.1.1) is used.
When publishing via TXT records, beware of other TXT records
published there for other purposes. They may cause problems with
size limits (see Section 3.1.4).
<<Seems soft, given the intense debate about SPF (re)use of TXT.
Perhaps: "respect other TXT records ...., and note that there may be problems
..."
It seems disingenuous to suggest that it is the pre-existing records which
are causing the problem!>>
No such suggestion has been made! I could not properly parse what kind of
text changes you wanted to make here and at what point in the paragraph.
Please do this proposal again, incorporating your changes in the text and
writing paragraph text with the changes.
[Page 9]
(either TXT and <<or> SPF RR types)
Changed
[Page 14]
Modifiers are not mechanisms:<<;>> they do not return match or not-match.
<<Definitely a nit!>>
As it is a nit, I've added this as proposed change that requires council
approval
[page 21]
The result of this new evaluation of check_host() is then considered
<<to be>> the result of the current evaluation with the exception that if no.
Similarly I saw this as a nit and put as proposed changed for approval
[Page 22
"%{i} is not one of %{d}'s designated mail servers."
-- a message with a little more info <<information>>, including the IP
address
that failed the check
Change "info" to "information" as you proposed
[Page 29]
Whereas <<Although>> the reasons for
changing the reverse-path are many and long-standing, SPF adds
enforcement to this requirement.
added as proposed changes that require council approval
[Page 31]
Service providers that offer mail services to third-party domains,
such as sending of bulk mail, may have to <<want to>> adjust their setup in
light
I added this change because I believe you hit the error as current text
makes it appear that use of SPF is required ("have to") where as its use
is optional. However I do think this will requre review of other people
and on the council.
[Page 34]
This could include returning "Pass" for an <ip> value
where the actual domain's record would evaluate to "Fail". See
[RFC3833] for a description of the <<delete "the">> DNS weaknesses.
I changed it. However as you already know I have absolutely no feeling for
when articles need and need not be present in enlish text. So somebody
else please confirm if this was correct change or not.
----
Note: when I say something was "changed" this does not mean the actual
draft text has already been changed. All the approved changes from
http://new.openspf.org/draft-schlitt-spf-classic_AUTH48_changes
will be sent to RFC Editor (through Meng) and only then would the
changes actually happen.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com