Re: [apps-discuss] draft-kucherawy-rfc5451bis
Dave Cridland <dave@cridland.net> Wed, 03 April 2013 10:18 UTC
Return-Path: <dave@cridland.net>
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 6AA9C21F850F for <apps-discuss@ietfa.amsl.com>; Wed, 3 Apr 2013 03:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 Ov2cFCIpzFV9 for <apps-discuss@ietfa.amsl.com>; Wed, 3 Apr 2013 03:18:35 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2550521F85C9 for <apps-discuss@ietf.org>; Wed, 3 Apr 2013 03:18:34 -0700 (PDT)
Received: by mail-ob0-f179.google.com with SMTP id vb8so1207446obc.24 for <apps-discuss@ietf.org>; Wed, 03 Apr 2013 03:18:34 -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=lXLoqsjuCTOizquUpypuhCvR80ISlhtzGMU30yzZdw8=; b=WrQioIK9tDLfJPnsfZw9OK0puTQgtRPJZHCVlsVUK0v/9bjuoSO1iizeZHiRyNZ+rw 3d6fY+zaKdhF9Epe/Kz5KRemJHP8mE12GddMXJqukhi+nRo7tMAPfh4GWFfRLw9QR5kf IMUVFB5dN/UUAOFroRR3yjbX7NKgI4qmiwQZU=
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=lXLoqsjuCTOizquUpypuhCvR80ISlhtzGMU30yzZdw8=; b=ZiWeBDYOoDnvilOHcvkoWDwPW1Db1nvjzSrPIA20Ed3WdIxtxGz4gdTHo0W8NMA8fn S+gbPN9H3XIq3sDaBptGgY9aUidwTDnHElblKQPcI1pIUIg7bAV6S1dl12ngpo14PEPj mHaejnvc4O/bWe7o50wtgI9GIUvrgTrvcCD9s3eASYmHzBZo1QFwM1PieO+txnFWNqNL apV6Xm5MQkHOJOABOTUaExZyqwbV6sZVmKHTMWigJWH6C4GkRBPl6YYNp9MzYUsMnh78 2v9D1OnykymxZH2VlSrA6JGWNMaaJRjy6gYiUTZbcyVZyBljfJcAwMxXQdf4DID1gOQQ ZWyw==
MIME-Version: 1.0
X-Received: by 10.182.118.1 with SMTP id ki1mr714539obb.2.1364984313981; Wed, 03 Apr 2013 03:18:33 -0700 (PDT)
Received: by 10.60.22.105 with HTTP; Wed, 3 Apr 2013 03:18:33 -0700 (PDT)
In-Reply-To: <CAL0qLwY=VLkUZ7KMenj_ORQDwLOSdFS=x+q0a3N2KcxaT9q=Gw@mail.gmail.com>
References: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com> <CAKHUCzxfBtLTt3p3moGgEQx+p5kr=-e2Mn58xaqNvWFGiW=Lpw@mail.gmail.com> <CAL0qLwY=VLkUZ7KMenj_ORQDwLOSdFS=x+q0a3N2KcxaT9q=Gw@mail.gmail.com>
Date: Wed, 03 Apr 2013 11:18:33 +0100
Message-ID: <CAKHUCzw5K3BHaWOk4GivJ-9tLvjo9v8exo=A0i8z3GeWdoQ8GQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary="f46d0447f24028c6b704d9722deb"
X-Gm-Message-State: ALoCoQmVjQqBl5RLFczPWr2TrBx5Shf5tPYfTJDtRYFAgMl1T7enFqKJ9yrdgRu3qix3LYAT+qBj
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 10:18:36 -0000
Murray, On Fri, Mar 22, 2013 at 7:21 PM, Murray S. Kucherawy <superuser@gmail.com> wrote: > > Hi Dave, thanks for the review. Comments below. > Thanks for the new versions (so many it confused me greatly trying to review the diffs - slow down!). > > On Fri, Mar 15, 2013 at 4:34 AM, Dave Cridland <dave@cridland.net> 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. > This satisfies my comment, FTR. >> >> >> 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. > Likewise, this satisfies my comment. >> >> >> 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?" :-) > Yes... And I think your §2.4 "Version Tokens" (new in -03) is good here. However, you have in -04's ABNF (with much elided): authres-header = "Authentication-Results:" [CFWS] authserv-id [ [CFWS] "/" [CFWS] version ] ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF ; the special case of "none" is used to indicate that no ; message authentication is performed version = 1*DIGIT [CFWS] ; indicates which version of this specification is in use; ; this specification is version "1", and the absence of a ; version implies this version of the specification method = Keyword [ [CFWS] "/" [CFWS] version ] ; a method indicates which method's result is ; represented by "result", and is one of the methods ; explicitly defined as valid in this document ; or is an extension method as defined below The conflation of the two different versions into one is (I find) confusing, though §2.4 goes a long way to correcting that - perhaps far enough, but I remain uneasy. I think your choices are: a) Rewrite the comment below the version production to point the reader to §2.4 b) Introduce two different productions, one for "authres-version" and one for "method-version", such that: authres-header = "Authentication-Results:" [CFWS] authserv-id [ [CFWS] "/" [CFWS] authres-version ] ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF ; the special case of "none" is used to indicate that no ; message authentication is performed authres-version = version [CFWS] ; indicates which version of this specification is in use; ; this specification is version "1", and the absence of a ; version implies this version of the specification method = Keyword [ [CFWS] "/" [CFWS] method-version ] ; a method indicates which method's result is ; represented by "result", and is one of the methods ; explicitly defined as valid in this document ; or is an extension method as defined below method-version = version [CFWS] ; indicates which version of the method specification is in use; ; those those methods defined in this specification are version "1", and the absence ; of a method-version implies this specification version = 1*DIGIT ; Version numbers are a simple string of digits; point versions are not allowed. c) Or, of course, both. d) Ignore me. Using (b) gives you the option of using those terms in §2.4 (and elsewhere as needed) to clarify which version you mean you mean, too. Obviously I'd rather you didn't do (d), but I'll accept it if you do. :-) Dave.
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Dave Cridland
- [apps-discuss] draft-kucherawy-rfc5451bis Murray S. Kucherawy
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Murray S. Kucherawy
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Alessandro Vesely
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Alessandro Vesely
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Dave Cridland
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Alessandro Vesely
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Dave Cridland
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Murray S. Kucherawy
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Murray S. Kucherawy
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Alessandro Vesely
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Murray S. Kucherawy
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Alessandro Vesely
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Scott Kitterman
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Murray S. Kucherawy
- [apps-discuss] The authentication server id, was … Alessandro Vesely
- Re: [apps-discuss] The authentication server id, … Murray S. Kucherawy
- Re: [apps-discuss] The authentication server id, … Alessandro Vesely
- Re: [apps-discuss] The authentication server id, … Murray S. Kucherawy
- Re: [apps-discuss] The authentication server id, … Alessandro Vesely
- Re: [apps-discuss] The authentication server id, … John Levine
- Re: [apps-discuss] The authentication server id, … Murray S. Kucherawy
- Re: [apps-discuss] The authentication server id, … Alessandro Vesely
- Re: [apps-discuss] The authentication server id, … Murray S. Kucherawy
- Re: [apps-discuss] The authentication server id, … Alessandro Vesely
- Re: [apps-discuss] The authentication server id, … SM
- Re: [apps-discuss] The authentication server id, … John Levine
- Re: [apps-discuss] The authentication server id, … Murray S. Kucherawy
- Re: [apps-discuss] The authentication server id, … Alessandro Vesely
- Re: [apps-discuss] The authentication server id, … Murray S. Kucherawy
- Re: [apps-discuss] The authentication server id, … Alessandro Vesely
- Re: [apps-discuss] The authentication server id, … Murray S. Kucherawy
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Dave Cridland
- Re: [apps-discuss] draft-kucherawy-rfc5451bis Murray S. Kucherawy