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

Alessandro Vesely <vesely@tana.it> Sun, 24 March 2013 12:04 UTC

Return-Path: <vesely@tana.it>
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 3D0CC21F8CD1 for <apps-discuss@ietfa.amsl.com>; Sun, 24 Mar 2013 05:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.569
X-Spam-Level:
X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
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 LElvPbmYVGyh for <apps-discuss@ietfa.amsl.com>; Sun, 24 Mar 2013 05:04:09 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5093E21F8A56 for <apps-discuss@ietf.org>; Sun, 24 Mar 2013 05:04:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364126647; bh=Om9KMafLKZooLDyXSoSbCoUW790GVHKC/ps7p1qgWWk=; l=2392; h=Date:From:To:References:In-Reply-To; b=LWqyJ2eMjoa2DQ2nZKPL80XFkAXaKvRIV/hI+quuWX70dPp2nWxcIWWlHfN0qAIjC iv6imiZUh92UnIVbfkuH+cpJGXATNPsWrxvN40a3Lcjo3jTXAIk2SSXhfS/8ZGoixp VcDMSPGxbwOdb/bgwwtgm3zKT2AfVYjaipFs0PjY=
Received: from [10.57.167.221] (93-32-179-143.ip34.fastwebnet.it [93.32.179.143]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sun, 24 Mar 2013 13:04:07 +0100 id 00000000005DC039.00000000514EEBB7.00000876
Message-ID: <514EEBB7.40205@tana.it>
Date: Sun, 24 Mar 2013 13:04:07 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com> <CAKHUCzxfBtLTt3p3moGgEQx+p5kr=-e2Mn58xaqNvWFGiW=Lpw@mail.gmail.com> <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <CAKHUCzwBrEPSVc4VtJMKZLm+5it3h7dLiW+YZ=_xO2OwP_rLoA@mail.gmail.com> <51458A59.8040206@tana.it> <CAL0qLwYEe9Wmvr-+eZL_yqChRf+a+11zRXCmW2Md9PGvH9PK-g@mail.gmail.com> <514DFAC8.7040406@tana.it> <CAL0qLwbqNUbPOYbXQEzM6X4=RLiqCQG2TbsO9A8PaE+a3Z3oNQ@mail.gmail.com>
In-Reply-To: <CAL0qLwbqNUbPOYbXQEzM6X4=RLiqCQG2TbsO9A8PaE+a3Z3oNQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: Sun, 24 Mar 2013 12:04:10 -0000

There's nothing intrinsically wrong with "value", albeit it is sometimes
a nuisance not to have a canonical form.  The point is how many A-R
parsers will need to be updated to comply with it, since "dot-atom"
didn't admit quotes.

Another point is about extensions.  I proposed "Keyword" because it
matches all the registered methods, and thus looks like what may seem to
be the spirit of the spec.  If 5451bis will say "value", then the
appointed expert will have no reason to oppose methods with long names
and properties, comprising spaces and punctuation like some sort of
filenames which require composition assistance in order to be spelled
correctly.  Is that what we want?

On Sat 23/Mar/2013 21:31:22 +0100 Murray S. Kucherawy wrote:
> What would be wrong with "dkim"="pass"?
> 
> The main difference between "token" and "value" is that the latter
> permits quoted strings.  I couldn't think of a good reason to proscribe
> those, and it's not like it makes parsing any more difficult; things
> that can parse "value" have been around for years.
> 
> -MSK
> 
> 
> On Sat, Mar 23, 2013 at 11:56 AM, Alessandro Vesely <vesely@tana.it
> <mailto:vesely@tana.it>> wrote:
> 
>      On Fri 22/Mar/2013 20:22:43 +0100 Murray S. Kucherawy wrote:
>     > I've revised the grammar in the next draft to avoid this
>     ambiguity.  Let
>     > me know if it works.  Essentially, "dot-atom" has been replaced by
>     > "value", which disallows the case you've illustrated here.
> 
>     Hm... that way it becomes possible to have "dkim"="pass".  I'd beg for
>     "token", which is somewhat simpler, but it allows dots.  Wouldn't it be
>     possible to have a grammar that matches the actual use?  I mean, e.g.:
> 
>     authserv-id = domain-name
>          method = Keyword [ [CFWS] "/" [CFWS] version ]
>          result = Keyword
>        property = Keyword
> 
>     "Keyword" is defined in RFC 5321, as well as "domain-name".  (It seems
>     to be useless to recall the definition from RFC 6376, as the domain
>     literal alternative that was in RFC 2821 has gone away.)
>     _______________________________________________
>     apps-discuss mailing list
>     apps-discuss@ietf.org <mailto:apps-discuss@ietf.org>
>     https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>