Mark Lentczner wrote:
draft-ietf-marid-protocol-03
My observations in protocol-03 (minus typos and stuff already
reported by Nate Lion):
Line 7 ("Sender-ID" (tm))
<< The SPF Record Format and Sender-ID Protocol
The Sender Policy Framework (SPF) Record Format and Protocol
Short title for all page headers:
<< The SPF Record Format and Sender-ID Protocol
The SPF Record Format and Protocol
Then replace the eight remaining strings "Sender-ID" by "SPF".
---------------------------------------------------------------
Line 186 (delete)
<< A compliant domain SHOULD publish authorizations for every
<< defined scope.
Big ISPs may not want to regulate how and where their users use
"their" 2822-From. That's a matter of the policy of the domain
owner, and it's the reason why we have more than one SPF scope.
---------------------------------------------------------------
Lines 206 - 212 (3 typos and a dubious MUST)
<< When a mail receiver decides to perform a Sender-ID check, it
<< MUST implement and evaluate the check_host() function (see
<< below) correctly and follow the requirements of the particular
<< scope under test.
When a mail receiver decides to perform a SPF check, it
determines the result of the check_host() function (see
below) following the requirements of the particular scope
under test.
SPF checks are defined in terms of the check_host() function,
and definitions IMHO don't qualify for an additional MUST.
<< While the tests as a whole or optional, once it has been
<< decided to perform a test it must as performed specified
<< so that the correct semantics are preserved between
<< publisher and receiver.
While the tests as a whole are optional, once it has been
decided to perform a test it MUST be performed as
specified so that the correct semantics are preserved
between publisher and receiver.
---------------------------------------------------------------
Line 244 (see also Nate's report)
<< This ensure that domains with published records and mail
<< receiver agree on the semantics of the scope.
This ensures that domains with published records and mail
receivers agree on the semantics of the scope.
Or say "the mail receiver" instead of "mail receivers".
---------------------------------------------------------------
Line 327 (delete)
<< A domain name MUST have a record of at least one type.
Domains without sender policy are perfectly okay.
---------------------------------------------------------------
Line 339
<< A Sender-ID compliant check SHOULD lookup both types. If
<< both types of records are returned for a domain, the SPF
<< type MUST be used.
A SPF compliant check SHOULD lookup both types if necessary.
This SHOULD is about "do try both ways if the first way didn't
work". It's not about receivers checking that both records
are identical, that's entirely the problem of the publisher.
The receiver is free to use whatever it gets first as is.
---------------------------------------------------------------
Line 455 ff. (see also Nate's report)
<< 2.1.8 Minor Version
Pleae move this stuff to section 2.1.2 (Version).
---------------------------------------------------------------
Line 520 (typo)
<< The function check_host() take four arguments:
The function check_host() takes four arguments:
Line 590 (typo)
<< If the records are in a cache, and has not expired, then
If the records are in a cache, and have not expired, then
Line 660 (nitpick)
<< A given mechanism type may always appear multiple times
A given mechanism type may appear multiple times
---------------------------------------------------------------
Line 681 (not more than one CIDR)
<< mechanism = name [ ":" domain-spec ] *( "/" *DIGIT )
mechanism = name [ ":" domain-spec ] [ "/" *DIGIT ]
---------------------------------------------------------------
Line 739 (KISS)
<< Global modifiers MAY appear anywhere in the record, but
<< SHOULD appear at the end
Global modifiers SHOULD appear at the end
As long as you don't say MUST the "MAY" is implied by a SHOULD.
---------------------------------------------------------------
Line 758 (delete)
<< A modifier is not allowed to be defined as both global and
<< positional.
That's IMHO obvious, same idea as for SINGULAR vs. MULTIPLE.
---------------------------------------------------------------
Line 767 (typo ?)
<< An intended side effect of these rules is modifiers cannot
<< be defined that modify other modifiers.
An intended side effect of these rules is that modifiers
cannot be defined to modify other modifiers.
---------------------------------------------------------------
Line 880 (typo)
<< When any mechanisms fetches host addresses to compare with <ip>
When any mechanism fetches host addresses to compare with <ip>
Line 887 (typo ?)
<< Should the server return domain does not exist (RCODE 3)
Should the server return "domain does not exist" (RCODE 3)
---------------------------------------------------------------
Line 909 (maybe)
<< Mechanisms after "all" will never be tested.
Mechanisms after "all" will never be tested. Any "redirect"
(5.1) has no effect in the presence of an "all" directive.
Line 918 (maybe)
<< The <scope>, <ip> and <sender> arguments remain the same
<< as current evaluation of check_host().
The <scope>, <ip> and <sender> arguments remain always the
same.
---------------------------------------------------------------
Line 1012 (the MX priorities are here IMHO irrelevant)
<< Then perform an address lookup on each MX name returned, in
<< order of MX priority.
Then it performs an address lookup on each MX name returned.
---------------------------------------------------------------
Line 1189 (typo)
<< provide an way to extend the record format in the future
provide a way to extend the record format in the future
Line 1195 - 1198 (delete)
<< This document reserves two modifiers for future definition:
<< "accredit" and "match_subdomains". Until these are defined,
<< implementations SHOULD ignore them. There is also one deprecated
<< modifier: "default". Implementations MUST ignore it.
This document is quite clear about unknown and future modifiers
without this paragraph. Obviously implementations MUST ignore
undefined modifiers. What else "SHOULD" they do, if returning
random results is not an option ?
---------------------------------------------------------------
Line 1211 (see also line 918)
<< The <scope>, <ip> and <sender> arguments remain the same as
<< current evaluation of check_host().
The <scope>, <ip> and <sender> arguments remain always the
same.
Line 1215 (typo ?)
<< the result of current evaluation.
the result of the current evaluation.
Line 1309 (typo)
<< a URL with the parameters check_host()
a URL with the parameters of check_host()
Line 1312 (upper case both Redirect ?)
<< during execution of a Redirect modifier, the explanation
<< string from the target of the redirect is used.
during execution of a Redirect modifier, the explanation
string from the target of the Redirect is used.
Line 1394 (typo ?)
<< evaluation limit of an implementation is reached
the evaluation limit of an implementation is reached
---------------------------------------------------------------
Line 1466 (KISS)
<< macro-string = *( macro-char / v-char-ms )
macro-string = *( macro-char / v-char-dm / "/" )
Line 1473 (delete)
<< v-char-ms = %x21-24 / %x26-7E
<< ; visible characters except "%"
Dito in lines 2076 and 2091 + 2092, get rid of v-char-ms, it's
the same as v-char-dm or slash.
---------------------------------------------------------------
Line 1467 and 2077 (ALPHA)
<< macro-char = ( "%{" ALPHA transformer *delimiter "}" )
Why not use the proper subset sSlLoOdDiIpPvVcCrRtT here ?
---------------------------------------------------------------
Line 1485 (as reported by Nate)
<< o = domain of <sender>
<< d = <domain>
o = original domain of <sender>
d = <domain> of evaluated SPF record
---------------------------------------------------------------
Line 1489 (typo ?)
<< v = the string "in-addr" for if <ip> is ipv4, or "ip6" if <ip>
v = the string "in-addr" if <ip> is ipv4, else the string "ip6"
What's the idea here, why not "ip4" resp. "in-addr.arpa" ?
---------------------------------------------------------------
Line 1497 (undefined term)
<< t = current timestamp in UTC epoch seconds notation
Please add a reference. Assume that I have an ISO timestamp
for the year 2170 and need a %{t} formula, or vice versa.
Line 1499 (dito)
<< uppercase versions of all these macros are URL-encoded.
uppercase versions of all these macros are percent-encoded.
IIRC that's now the preferred term (compare 2396bis)
I'll try to read the remaining 800 lines in protocol-03 later,
but as far as I'm concerned the stuff is as good as ready for
standards track.
Bye, Frank