wayne wrote:
The two main problems with the newer xml2rfc are:
1) It is breaking lines in places I don't want it to.
Yes, that's bad, I proposed ‍ (zero width joiner)
as a way to bypass it on demand.
the html output had some rough edges.
I'm certainly not interested in any xml2rfc HTML output.
Marshall proposed to use its HTML for diffs, but probably
this was just the normal exchange of "post-MARID" flames.
Maybe the spec really is close to perfect, but I suspect
not. ;-)
Apparently you have _completely_ ignored all points in my
-01pre2 report, I've already found three old issues up to
line 636. See below for this short first part, bye, Frank
-01pre5 nits in no particular order:
* Please add a short "document history" with the modifications since
draft -00. Especially list modifications caused by IESG [Discuss]
votes. Add the usual note that this part should be removed by the
RfC editor in the final document - xml2rfc supports this kind of
note, but I've never tested how.
* The RfC 2119 key words REQUIRED, SHALL, SHALL NOT, and OPTIONAL are
not used. Probably irrelevant, but Bruce apparently checks this.
* "Checking other identities against SPF records is NOT RECOMMENDED"
| Checking other identities against the SPF records defined in this
| memo is NOT RECOMMENDED
It's perfectly okay to check the PRA against spf2.0/pra policies,
or a "submitter identity" against spf2.0/submit, etc.
=> Already reported in my -01pre2 nits.
* "many MTAs will still accept such things as source routes (see [RFC2821]
appendix C), the %-hack (see [RFC1123]) and bang paths (see [RFC1983]).
These archaic features have been maliciously used to bypass security
systems."
They MUST accept source routes, archaic or not, it's a MUST in 2821,
=> already reported in my -01pre2 nits.
There's no special problem with the %-hack from the POV of SPF, the
RHS behind the first unquoted "@" is the domain (or domain literal).
Otherwise explain what you expect in this case.
* 2.5.4 "it should be made clear that text is not trusted."
| it should be made clear who proposed this explanation.
Maybe a bad case of DEnglish, I miss an article for the word "text".
* "greylisting" where by the MTA can issue an SMTP reply code of 451
My 1977 dictionary still has "whereby" in one word (?)
* client MAY also perform lookup of both types in parallel.
? client MAY also perform a lookup of both types in parallel.
? client MAY also look up both types in parallel.
* If for a domain both types are obtained but their contents do not
match, the SPF client SHOULD return a "PermError" result.
| match, the SPF client MAY return a "PermError" result.
It could simply pick SPF before TXT and be done with it. I still
think that there can be valid reasons for different records, e.g.
no exp= in the TXT version due to size limits.
=> Already reported in my -01pre2 nits.