X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Delivered-To: barryleiba.mailing.lists@gmail.com
Received: by 10.107.163.148 with SMTP id m142csp79116ioe;
        Fri, 8 Aug 2014 06:49:30 -0700 (PDT)
X-Received: by 10.68.95.225 with SMTP id dn1mr24265925pbb.126.1407505770391;
        Fri, 08 Aug 2014 06:49:30 -0700 (PDT)
Return-Path: <abnf-discuss-bounces@ietf.org>
Received: from mail.ietf.org (mail.ietf.org. [2001:1900:3001:11::2c])
        by mx.google.com with ESMTPS id u1si2548036pdd.116.2014.08.08.06.49.29
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 08 Aug 2014 06:49:30 -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 5DD051B29CB;
	Fri,  8 Aug 2014 06:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1407505769; bh=KkNLNuNjFDJJXYnC2r3dUnXYr2D/u9Oxm8TugYCmbvQ=;
	h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc:
	 Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:
	 List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender;
	b=DWK6W0YtBefPzxG81+Odx8Mwrp8Ay72gXk54d42iEevxHA55eN3jP7di2pRrHKGAo
	 DYeJWX5WvWiehgrGrY2WrR1TyaX6UOhb0BHDycb4dE+IPXMeiRl61GjXx7T1rvpxmp
	 /YTEIF4yW+yP0Y8i0l96cKShuMo7dB2sQJlw2TXk=
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 DFCC61B29BC
 for <abnf-discuss@ietfa.amsl.com>; Fri,  8 Aug 2014 06:49:27 -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_65=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 a_Sl2s_EWd1d for <abnf-discuss@ietfa.amsl.com>;
 Fri,  8 Aug 2014 06:49:26 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90])
 (using TLSv1 with cipher RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 09A141B29B9
 for <abnf-discuss@ietf.org>; Fri,  8 Aug 2014 06:49:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=cisco.com; i=@cisco.com; l=3218; q=dns/txt; s=iport;
 t=1407505766; x=1408715366;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-transfer-encoding:mime-version;
 bh=TsaH8VPb+zBQbnLGUKHgV35pvrQqAov2WmPAjvM/C78=;
 b=A2AMsHDlLRghUCJXyds32UrXYL5luOCgG9OPzXm3eQ7mbZ4wu3hdPHif
 4iu/0l/fQI1Cev6nMIQ5kK0M4YuwqZ0g8zEAysWpblcDCbXoZniQKQMNq
 p4dVKYf4mHQ1VoXkWMbf+AYiB/bxTdSyMlWA85bmbqKSRv0rcqJHgvZ3L E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFABvV5FOtJV2b/2dsb2JhbABagw1SV8xkCodIAYETFneEAwEBAQMBAQEBNzQLEAIBCBgeECcLJQIEDgWIOggNxWATBI8ZMweDL4EcBZEUhlyENYt8iHaDV2w
X-IronPort-AV: E=Sophos;i="5.01,825,1400025600"; d="scan'208";a="67629867"
Received: from rcdn-core-4.cisco.com ([173.37.93.155])
 by alln-iport-3.cisco.com with ESMTP; 08 Aug 2014 13:49:25 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86])
 by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s78DnPKF028987
 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
 Fri, 8 Aug 2014 13:49:25 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by
 xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 8
 Aug 2014 08:49:25 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Ned Freed <ned.freed@mrochek.com>
Thread-Topic: [abnf-discuss] Case-sensitive string constants in ABNF?
Thread-Index: AQHPswxB36iWWJQGcU6h8If2CMSU+pvGuQih
Date: Fri, 8 Aug 2014 13:49:24 +0000
Message-ID: <0EFEDBFE-D322-4DB4-A5AC-CBDBA49D5118@cisco.com>
References: <53E26154.8020308@alum.mit.edu>
 <01PB24L5SC060000SM@mauve.mrochek.com>
 <53E27A1A.10609@alum.mit.edu>,<01PB4MM257OE0000SM@mauve.mrochek.com>
In-Reply-To: <01PB4MM257OE0000SM@mauve.mrochek.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/abnf-discuss/vq_z45wo1_aeEqGgPpicTVtgR8Y
Cc: "abnf-discuss@ietf.org" <abnf-discuss@ietf.org>,
 Paul Kyzivat <pkyzivat@alum.mit.edu>
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"
 <abnf-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abnf-discuss>,
 <mailto:abnf-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abnf-discuss/>
List-Post: <mailto:abnf-discuss@ietf.org>
List-Help: <mailto:abnf-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abnf-discuss>,
 <mailto:abnf-discuss-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: abnf-discuss-bounces@ietf.org
Sender: "abnf-discuss" <abnf-discuss-bounces@ietf.org>

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" <ned.freed@mrochek.com> 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

_______________________________________________
abnf-discuss mailing list
abnf-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/abnf-discuss