Re: [apps-discuss] draft-kucherawy-rfc5451bis

["Murray S. Kucherawy" <[e-mail]>]

Hi Dave, thanks for the review.   Comments below.

On Fri, Mar 15, 2013 at 4:34 AM, Dave Cridland <[e-mail]> wrote:

> For the most part, this document looks fine and solid.
>

Hooray!


>
> Two items concern me in a major way; one further item has me mildly
> nervous.
>
> First, the minor one:
>
> The header includes definition of a version ABNF production optionally
> following the authentication server's identity. It took me some time to
> find the note of how to treat this; I didn't see any examples with it
> present either.
>

I've updated one of the examples to include a version.


>
> Second, the first major one:
>
> The examples tend to imply, for the most part, a canonical form to the
> header, which places CFWS is only particular places. In particular, all the
> examples are of the form auth-srv-id "; " method "=" result, with some
> optional properties and/or reason, with one single exception (which
> includes a comment in lieu of a reason). It's not immediately apparent to a
> comparatively novice reader that the following header field is valid:
>
> Authentication-Results: foo.example.net (My mailserver) / (I am number) 1
> (You see) ; dkim (Because I like it) /2 (Two yay) = (wait for it) pass ;
> policy (And a dot can go here) . (Like that) fruit (which surprised me) =
> (because I was not expecting it) banana
>

> I appreciate it's always nicer to only write pretty examples, but given
> the specification, providing a nasty one is probably needed, lest people
> expect to take a whitespace delimited token and split it on '='. For some
> reason I particularly wasn't expecting the CFWS around the dot. (Maybe
> that's because I'm out of practise with header parsing).
>
> In any case, highlighting this with an example seems appropriate and
> useful.
>


Copied to the draft, with some adjustments to make it compliant and fit the
width limit.


>
> Thirdly, one more major concern:
>
> You'll note that I included a version for the method in my example above.
> The definition for this, from the comments in the ABNF, suggests that this
> relates to the version of RFC 5451 and successors used, but this seems
> unlikely - I'm also at a loss as to what a receiving implementation should
> do with such a method, since the handling of version seems to be specified
> only for the version number after the auth-srv-id.
>
> I have a vague suspicion that the correct thing to do here may be to
> deprecate the method version entirely, but I might be missing something -
> still, it doesn't appear to relate to the method, but the header field.
>
>
>
The method version refers to the method itself, which is specified
elsewhere; the authserv-id version refers to this draft and thus the syntax
of this header field.  The idea is that if you find a version after an
authserv-id that you can't handle, you stop trying to parse right away
because what follows might not be what you expect.  In terms of a method
version, the parser should ignore a method result if the version of the
version is not supported in case the semantics of the result have a
different meaning.  If, for example, DKIM v2 (were such a thing to exist)
yielded a "pass" for different reasons than v1 did, a consumer of this
field might not want the altered semantics to apply.  This is a way to
indicate this and let the consumer decide.

Is your reply to this "You should say that?"  :-)

-MSK