X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Delivered-To: barryleiba.mailing.lists@gmail.com
Received: by 10.107.163.148 with SMTP id m142csp93098ioe;
        Fri, 8 Aug 2014 08:35:57 -0700 (PDT)
X-Received: by 10.70.88.205 with SMTP id bi13mr25086720pdb.43.1407512156766;
        Fri, 08 Aug 2014 08:35:56 -0700 (PDT)
Return-Path: <abnf-discuss-bounces@ietf.org>
Received: from mail.ietf.org (mail.ietf.org. [4.31.198.44])
        by mx.google.com with ESMTPS id k10si2759968pdr.197.2014.08.08.08.35.56
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 08 Aug 2014 08:35:56 -0700 (PDT)
Received-SPF: pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 4.31.198.44 as permitted sender) client-ip=4.31.198.44;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 4.31.198.44 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 B3C921B2B95;
	Fri,  8 Aug 2014 08:35:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1407512155; bh=/dG/VRJ3bajvc/L/hVq1ppnAyHkiDPjGWBt5xFFgTCU=;
	h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc:
	 Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:
	 List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender;
	b=Xweh1OObF4QLJn3XTN0/cbxiVv6pf8iQghht8cAYqZfmBUj5aWE2aXIxJMdFrFmIX
	 GyCF0szt04OXqA8OhJaO2RMbQRTsW4EtwoZ6DdoLqCRzKg8YCqQCaiZJ3duDvMwULH
	 EwSxIVbXwdvV8yqyCfY9SZOaSD62VUhIfY4yW3GM=
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 681461B2B84
 for <abnf-discuss@ietfa.amsl.com>; Fri,  8 Aug 2014 08:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level: 
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 J_CHICKENPOX_65=0.6, SPF_SOFTFAIL=0.665] autolearn=no
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 2XxU1vtuUbpS for <abnf-discuss@ietfa.amsl.com>;
 Fri,  8 Aug 2014 08:35:52 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net
 (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17])
 by ietfa.amsl.com (Postfix) with ESMTP id DF5931B2AF2
 for <abnf-discuss@ietf.org>; Fri,  8 Aug 2014 08:35:51 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51])
 by qmta10.westchester.pa.mail.comcast.net with comcast
 id cEtZ1o00616LCl05AFbrY6; Fri, 08 Aug 2014 15:35:51 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164])
 by omta06.westchester.pa.mail.comcast.net with comcast
 id cFbr1o0023ZTu2S3SFbr2x; Fri, 08 Aug 2014 15:35:51 +0000
Message-ID: <53E4EE56.9050807@alum.mit.edu>
Date: Fri, 08 Aug 2014 11:35:50 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, 
 Ned Freed <ned.freed@mrochek.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>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
 s=q20140121; t=1407512151;
 bh=bsKYKmd2PtE/rQu7ocbNY6CF5TWfYqhcqP8QHKXeDkY=;
 h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject:
 Content-Type;
 b=FeU6JO1cQ+cV5ngHofMbzuymxH3jGH2HjPi2B5mjx69rdgQ848/6gKeaUTViNqVNJ
 xKmeGHQTwfV8trnvArfAY6D3+CrPkJJ2nAPh9+WKiJeTTqJRJCfbD6DU/+OgJlpRPU
 GBq4Ue/U/yJSFOcVr2KzYzN3ABQ9jvNlgFFE6CuWH/oK6daco5oqEhxsiqhScANA24
 u1OWL7rWZNRkO5mlLXToSRRwW7L8rIjg1FKMUWzAE4IOxT8Urgb7n/dixL05Gi8plk
 J79cCtQYD0QWUJseKiYcNzevSIPvqXFAtXD+5zByFlNIQEFvs7k8eNVGxKw5O31Vix
 1WnySAi2Ie/kg==
Archived-At: http://mailarchive.ietf.org/arch/msg/abnf-discuss/-IM79S6wIBB5ghJg0RTKxiRtsrU
Cc: "abnf-discuss@ietf.org" <abnf-discuss@ietf.org>
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: abnf-discuss-bounces@ietf.org
Sender: "abnf-discuss" <abnf-discuss-bounces@ietf.org>

On 8/8/14 9:49 AM, 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" <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.

I think it would be helpful to discuss what it would mean to use ABNF 
for matching unicode input. But it is critical to have people who are 
very knowledgeable about unicode leading that discussion.

	Thanks,
	Paul

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