Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F2321F8D66 for ; Fri, 15 Mar 2013 04:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5agJJM5aMWKj for ; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7DB21F8ABD for ; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so3192248oag.25 for ; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uvoqz0MZEHKnBPZgbkN653+BMZ7CFM5If6e0mCvqcEk=; b=GNoXtQKWcOSD0vM7KP03kD0nU92VmRcOeCake/JoBA8b5jbJ4fppjRFdJTol+zGyml YS7emGDabcvkRGuwfORkYOQs1lDRRrrNwBAFonA+yk7wdtNqXap19xhlLuP+cahlZE23 WrgB0FonH/OXU52XAt8FTZQnmrDmJnRxlW238= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uvoqz0MZEHKnBPZgbkN653+BMZ7CFM5If6e0mCvqcEk=; b=AtjaY4Qumckov25GEI6b6k3kspf1czSSSfVPbAWXzWlwvttrayW72utRSpCbMK3SCO qe7qKSwtvXy1+JcVVQ0UBvDSt//gpBG1yqf1wzA+FXk0xE40KlAxBMhOQBEqoH9y4P4m 52/lPxXVwTOhLT8zcr1kZBoHJtTeCFqpBu1j44YcVoDZDUd0i3qHGXd0xEZzNPymogC0 9RhCx84HS602HnITEUdCJb7obSe9wA0xu3t5Elub6jEnJ5aSw/x+tiSkZXhmP1XmVw/q Kg06MRsIKmC9Aax0U8i+9s+tlamMtnXiVuSu/CXBJSFVvBslzKqUuuwSUp75P40Op2Wi f6HA== MIME-Version: 1.0 X-Received: by 10.60.10.226 with SMTP id l2mr2834490oeb.67.1363347243187; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Mar 2013 11:34:03 +0000 Message-ID: From: Dave Cridland To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=e89a8fb1f8d022d7fe04d7f5047a X-Gm-Message-State: ALoCoQmoQHLgFYVTflBUqMZrH5mBN10ZWy6vZDXfdOpAsQSv6yN3sJcYxR10bMubGbV9yyozLjl1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 11:34:04 -0000 --e89a8fb1f8d022d7fe04d7f5047a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 14, 2013 at 7:40 PM, Murray S. Kucherawy wrote: > I've uploaded an update to draft-kucherawy-rfc5451bis for review. It > incorporates the feedback I've received over the last few months since the > last version. > > https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ > > I've not seen this document before, nor its predecessor, so I'm casting a fresh pair of eyes on it. This may result in my not having understood the draft, but I'll pretend that's the draft's fault rather than it possibly being my own idiocy. For the most part, this document looks fine and solid. 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. 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. 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. Dave. --e89a8fb1f8d022d7fe04d7f5047a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 14, 2013 at 7:40 PM, Murray S. Kucherawy <superuser@= gmail.com> wrote:
I'v= e uploaded an update to draft-kucherawy-rfc5451bis for review.=A0 It incorp= orates the feedback I've received over the last few months since the la= st version.

https://datatracker.ietf.org/doc/draft-kucherawy-rfc545= 1bis/


I&= #39;ve not seen this document before, nor its predecessor, so I'm casti= ng a fresh pair of eyes on it. This may result in my not having understood = the draft, but I'll pretend that's the draft's fault rather tha= n it possibly being my own idiocy.

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

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 fol= lowing the authentication server's identity. It took me some time to fi= nd the note of how to treat this; I didn't see any examples with it pre= sent either.

Second, the first major one:

The examples tend to imply, for the most part, a can= onical form to the header, which places CFWS is only particular places. In = particular, all the examples are of the form auth-srv-id "; " met= hod "=3D" result, with some optional properties and/or reason, wi= th one single exception (which includes a comment in lieu of a reason). It&= #39;s not immediately apparent to a comparatively novice reader that the fo= llowing 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) =3D (wait for it) pass ; polic= y (And a dot can go here) . (Like that) fruit (which surprised me) =3D (bec= ause 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 i= s probably needed, lest people expect to take a whitespace delimited token = and split it on '=3D'. For some reason I particularly wasn't ex= pecting the CFWS around the dot. (Maybe that's because I'm out of p= ractise with header parsing).

In any case, highlighting this with an exam= ple seems appropriate and useful.

Thir= dly, one more major concern:

You'l= l note that I included a version for the method in my example above. The de= finition for this, from the comments in the ABNF, suggests that this relate= s 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 wit= h such a method, since the handling of version seems to be specified only f= or the version number after the auth-srv-id.

I have a vague suspicion that the correct t= hing to do here may be to deprecate the method version entirely, but I migh= t be missing something - still, it doesn't appear to relate to the meth= od, but the header field.

Dave.
--e89a8fb1f8d022d7fe04d7f5047a--