On Wed, 6 Oct 2004, Mark Lentczner wrote:
Friends -
Contributors
------------
The authors of the DMP, RMX and Vixie proposals are listed in the
references section. Is that not enough?
I don't think so. I recommend reading my previous to ietf/mxcomp post with
example of the text the properly enumerates all parties involved:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03973.html
And see text in responsible-submitter-00 draft and how that lists prior work.
And please remove double-mention of MARID/mxcomp from contributors section.
New RR
------
The wording an design of this section was done in conjunction with DNS
guru types. It doesn't include the stronger language they desired
which would have made the new RR type required for both publishers and
receivers.
It is by design that publishers can choose not to publish the TXT
format if they wish. One can only hope for a day when deployment makes
this a reasonable option.
It is also by design that which order to query the types isn't
specified. Implementations may choose to query both simultaneously.
My personal perference is perfectly represented by the following:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03802.html
"> > Why not:
> > SHOULD publish SPF2
> > MAY publish TXT
> > MUST publish at least one of the two."
Repeated Modifiers
------------------
Section 4.6.3 says "The same key MUST NOT appear in more than one
modifier in a record." The intent is that modifiers cannot be
repeated, and any repetition results in a syntax error (PermFail).
Why can they not be repeated?
Modifiers are something that some clients are able to process and some
can not. Its up to the client to be able to decide if repetition of
the modifier is to be considered an error in regards to that modifier
or not. But I don't think this should be disallowed for all modifiers
directly by the protocol draft.
As this is a specification, it should not sanction tolerance of
non-well-formed records, or records with ambiguous semantics (such as
having two "exp=" sections). Implementations, will of course, vary in
their degree of strictness.
Case Sensitivity
----------------
Since the specification is defined using the ABNF of RFC 2234, all
alphabetic literal characters (those in double quotes) in the syntax
are case insensitive. So, yes, "v=spf1" and "V=SPF1" and "v=SpF1" are
technically all legal and the same. Similarly, "+a" and "+A" are the
same. On the other hand, the characters that make up domain-spec and
macro-string, as they are specified with percent notation (as in
%x30-7E), are case sensitive.
I have long suspected that this is NOT really agreed upon understanding
of SPF v1. Comments?
It would be good that you specifically mention in the protocol text that
version and operator and modifier names should be treated as being
case-insensetive.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net