ietf-822
[Top] [All Lists]

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt

2005-05-09 16:37:47

Bruce Lilly wrote:
 
Review of draft-kucherawy-sender-auth-header-02 by B. Lilly

Is your review tool also available as Web form ?  Something
like proto-I-D in, death sentence (or whatever) out ?

The "idnits webservice" (and related tools like rfcdiff) does
not work from my POV, I get no output, only the "usage" page:

<http://ietf.levkowetz.com/tools/idnits/idnits.pyht>

   [X] ABNF [R4.RFC2234]

Somewhat beside the point, but this draft doesn't contain the
string "2234" or "ABNF".  And if you check it anyway Scott H.
wants us to use the new 2234bis in the References.

              20:0: error: Empty rule
              22:0: error: Empty rule
 
   Clearly, the "ABNF" is badly broken.

That's not helpful, so how should we reference terms defined
elsewhere ?  Especially terms defined NOWHERE in ABNF, as all
2045 or 2231 terms.  Sorry, but I'm getting _very_ angry if I
see this, it's a royal PITA, see also many USEFOR articles.

However, the status as defined in BCP 9 should be:

etc., the dysfunctional Web interface claims that there should
be less verbose output formats better suited for posting.

   [X] None of the above.

Is that your personal opinion or idnits output ?  I'd guess
that Murray wants FYI / proposed standard / experimental.

[X] missing or inadequate IANA considerations

= missing 3864 header registration form

[X] incompatible with the Internet Architecture

If that's American humour please add an I18N version.

[X] uses non-standard terminology

Where ?  It certainly explains "border-MTA", although I'd
prefer MX.  Okay, I saw it later, your "header" hobby horse.

Trust needs to be end-to-end.

No.  If you can partition the net into "ours" and "not-ours",
and find an imaginary border between these partitions along the
lines of "our MX", then you can reduce this admittedly simple
check to the hop from the last "not ours" to the first "ours"
MTA,  The concept is known as MX.

Unencrypted, unsigned content is trivially forged.

Try it, forge a MAIL FROM me and send it to any receiver using
SPF checks.  Hint: it's not impossible.  In practice you can't.

there exist domain names which have no corresponding IP
addresses.

So what ?  The last MTA used on the "not ours" side has an IP.

SMTP transfer does not alter content except for addition of
time-stamp fields (a.k.a. Received fields), and (at "final"
delivery) a Return-Path field.

Obviously this draft proposes a new trace header field.  In
practice MDAs already create numerous additional fields like a
very important X-Envelope-To or a X-Spam-Prev-Subject (that's
the original subject before adding ***SPAM*** to it).  Just
two arbitrary examples found in my inbox.

modification of message header content in transit.

In other words it adds a header field, but does not modify any
existing header field.

[X] [R10.FYI18]; pay particular attention to the standard
                 definition of "header".

That won't stop him to find "bang path" and "mail path".
 
[X] [R57.Errata]

That's a dubious source, I've tested it two times, and so far
nothing happened (after an inquiry I got the confirmation that
they got it for the first).  The second was about RfC 3978.

Try to make these reviews shorter, e.g. remove anything that's
clearly not applicable.  You managed to reference your own I-D,
therefore you could do the same with 2234bis or taobis.

                           Bye, Frank