X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Delivered-To: barryleiba.mailing.lists@gmail.com Received: by 10.107.163.148 with SMTP id m142csp94137ioe; Fri, 8 Aug 2014 08:44:20 -0700 (PDT) X-Received: by 10.70.34.104 with SMTP id y8mr24690715pdi.7.1407512660220; Fri, 08 Aug 2014 08:44:20 -0700 (PDT) Return-Path: Received: from mail.ietf.org (mail.ietf.org. [2001:1900:3001:11::2c]) by mx.google.com with ESMTPS id y5si2776953pdm.221.2014.08.08.08.44.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Aug 2014 08:44:20 -0700 (PDT) Received-SPF: pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) client-ip=2001:1900:3001:11::2c; Authentication-Results: mx.google.com; spf=pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) smtp.mail=abnf-discuss-bounces@ietf.org; dkim=pass header.i=@ietf.org Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5221B2BBA; Fri, 8 Aug 2014 08:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1407512659; bh=kz4FTtC3gwbIqYl+jXDohMFiLyMWoPZNJeGbowfZEIE=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=gm5nPnQRaN6FGczqKS30G8yGBvjfwRHvXfHXxNzbPknNJttqbI5yS2po4V7j7n/Pf A9yKzekEEqcCTTOQZNj+yZV9IE6q2E70E6ilMmYF7pWiljvAsrggD0qalXPfZ9EjOi KaUp0zI9/3W42v/EgJd3620GdutaDFWM75Vic2XU= X-Original-To: abnf-discuss@ietfa.amsl.com Delivered-To: abnf-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14B31B2BB8 for ; Fri, 8 Aug 2014 08:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f-xuQBhK52D for ; Fri, 8 Aug 2014 08:44:16 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43531B2BAE for ; Fri, 8 Aug 2014 08:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6134; q=dns/txt; s=iport; t=1407512655; x=1408722255; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ym3KAps32H5n6uC8f3dLQCRcKpijRTaqUi/w/SyqRfY=; b=D9QfCdcSYA+AUzxQRlV/m+nXa8kXOUboKATLfqKAEsvb2OoVef1BAIg+ vpizidLdaQz+Sv/HrlxWJiCeJtzVjBkqwq+ZVAQ/vPYrmlYewGsvt5NrD sBQTTQxdXA/JZ8pKeVg89zWVs8ZLK69lRTNp4l8Xt+CSI1UojOR6Ja3KX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAOXv5FOtJV2Y/2dsb2JhbABagw1SVwSCc8luCodIARl6FneEBAEBBAEBASAROgsQAgEIGAICJgICAiULFRACBA4FiEINr1qVeRMEgSyNbTMHgnk2gRwFkRSGXIQ1i3yIdoNXbIFG X-IronPort-AV: E=Sophos;i="5.01,825,1400025600"; d="scan'208";a="67663779" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 08 Aug 2014 15:44:11 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s78FiBNr031978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Aug 2014 15:44:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 10:44:11 -0500 From: "Joe Hildebrand (jhildebr)" To: Ned Freed Thread-Topic: [abnf-discuss] Case-sensitive string constants in ABNF? Thread-Index: AQHPswxB36iWWJQGcU6h8If2CMSU+pvGuQihgAAPS4A= Date: Fri, 8 Aug 2014 15:44:10 +0000 Message-ID: <37269A74-EC2D-428B-9082-8CA2D8B00574@cisco.com> References: <53E26154.8020308@alum.mit.edu> <01PB24L5SC060000SM@mauve.mrochek.com> <53E27A1A.10609@alum.mit.edu> <01PB4MM257OE0000SM@mauve.mrochek.com> <0EFEDBFE-D322-4DB4-A5AC-CBDBA49D5118@cisco.com> In-Reply-To: <0EFEDBFE-D322-4DB4-A5AC-CBDBA49D5118@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140730 x-originating-ip: [10.129.24.156] Content-ID: MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/abnf-discuss/JYcOtpk6wlGk14p45bkIlsxpD_U Cc: "abnf-discuss@ietf.org" , Paul Kyzivat Subject: Re: [abnf-discuss] Case-sensitive string constants in ABNF? X-BeenThere: abnf-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "General discussion about tools, activities and capabilities involving the ABNF meta-language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: abnf-discuss-bounces@ietf.org Sender: "abnf-discuss" And of course, now that I'm at a computer, I realize we more-or-less did that anyway, but didn't really talk about it much. e.g.: unescaped = %x20-21 / %x23-5B / %x5D-10FFFF I would much have preferred to be able to have an easy way of saying "unicode scalar value except for C0 controls, dquote, or backslash", then having a rational discussion about whether there are other controls or non-printable classes that should be excluded. As it is, I *hate* that it looks like half surrogate pairs are allowed, except in our world there's technically no way to get them into this grammar. In the JavaScript world, that's not the case, and some implementations generate CESU instead of UTF-8 (for example), causing compliant implementations to reject the protocol on decode. Worse, some implementations blindly replace the surrogate with U+FFFD, losing data. My point is that without slightly better ways to reason about unicode-based protocols, we're likely to repeat similar mistakes in the future leading to worse interop than we want. On 8/8/14, 1:49 PM, "Joe Hildebrand (jhildebr)" wrote: >The JSON RFC would have been a LOT clearer expressed as Unicode. It is, >kind of, except for some messy edges that lead to interoperability >issues.since JSON can be expressed as several different encodings on the >wire, when the spec talks about a given character, it really means a >codepoint expressed in the target encoding. If we had decided to deal >with the u+2028/9 problem (they are newlines, and we might have decided >to require them to be escaped in strings like \n, in order to align >better with JavaScript), we would not have been able to adequately >capture this in ABNF. > >Mobile/terse. DYAC. > >On Aug 8, 2014, at 7:34 AM, "Ned Freed" wrote: > >>> On 8/6/14 2:29 PM, Ned Freed wrote: >>> >> Has there ever been consideration of supporting case-sensitive >>>string >>> >> constants in ABNF? >>> > >>> >> While the case-insensitive ones are more often than not what is >>>needed, >>> >> some protocol designs have places where case-sensitivity is >>>desired. It >>> >> is possible to accomplish this now, using numeric byte values. But >>>it is >>> >> hard, both to read and to write. >>> > >>> > Agreed. >>> > >>> >> I see no *technical* problem with supporting both kinds. The only >>> >> questions are: >>> >> - Is it a good idea to support both? (Or is *not* supporting them >>> >> intentional, to discourage case-sensitive syntaxes?) >>> > >>> >> - What syntax to use in ABNF to denote the two types, while >>>remaining >>> >> backward compatible. >>> > >>> >> Regarding the syntax, a straightforward approach would be to define >>> >> case-sensitive strings using a new delimiter. Single quote is a >>>likely >>> >> candidate since it is currently unused. >>> > >>> > It's the obvious thing, but I worry it will be confusing. >> >>> Yeah, it worries me too. People are already confused about quoted >>> strings being case insensitive. >> >>> >> Another possibility for syntax would be to allow an optional prefix >>>on >>> >> char-val. For example: %S"abc", %I"abc". >>> > >>> > I like the idea of using prefixes. I don't especially care about the >>> > syntax. >> >>> I like the concept. It puts the choice in your face without being >>>overly >>> inconvenient. And the % syntax seems to fit in well with what is there. >> >>> But it isn't obvious what type indicator characters to use to denote >>> case sensitivity and the converse. The %S and %I were the first things >>> that came to mind, but I don't love them. >> >>> It also occurred to me that there might be other string modifiers that >>> people might want. E.g., unicode. Once you get to unicode it might not >>> make sense to talk about case-insensitive comparison. >> >> There may be. But unicode opens the door to all sorts of other >>considerations. >> There's all kinds of mechanism surrounding case, case conversion, and >> case sensitivity. Absent specific requirements, I don't think it makes >> sense to try and design such a mechansim to add unicode support to >> ABNF. >> >> Ned >> >> _______________________________________________ >> abnf-discuss mailing list >> abnf-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/abnf-discuss > -- Joe Hildebrand _______________________________________________ abnf-discuss mailing list abnf-discuss@ietf.org https://www.ietf.org/mailman/listinfo/abnf-discuss