X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Delivered-To: barryleiba.mailing.lists@gmail.com
Received: by 10.107.163.148 with SMTP id m142csp93116ioe;
        Fri, 8 Aug 2014 08:36:06 -0700 (PDT)
X-Received: by 10.66.66.133 with SMTP id f5mr24631588pat.81.1407512166460;
        Fri, 08 Aug 2014 08:36:06 -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 kk10si6299011pbd.238.2014.08.08.08.36.05
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 08 Aug 2014 08:36:06 -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 438491B2BA9;
	Fri,  8 Aug 2014 08:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1407512165; bh=LqIyUGxC1ZQJ5Q6usJqZkxs+eQqCC6XGAUINKoNo5io=;
	h=MIME-version:Message-id:Date:From:In-reply-to:References:To:Cc:
	 Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:
	 List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender;
	b=e240jolxeT9Nkyi/Fka57Gldmccg/bliDOxlH+ehPa8qRiTj2Uu6rX+M0AEzIQ7VZ
	 vQEgUIuoVyVhoBre355F0OGbPJcxu54ge/T4/NM8LgTQCUmQc1lOoEXSO/EFBe4vcF
	 7cUixz3bamwhqVn7ude4Z4v0OnKpGfQyBCxFxLow=
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 120201B2BA6
 for <abnf-discuss@ietfa.amsl.com>; Fri,  8 Aug 2014 08:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Level: 
X-Spam-Status: No, score=-1.403 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, RP_MATCHES_RCVD=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 nQguF0ndHLdr for <abnf-discuss@ietfa.amsl.com>;
 Fri,  8 Aug 2014 08:36:02 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17])
 by ietfa.amsl.com (Postfix) with ESMTP id 848761B2AF2
 for <abnf-discuss@ietf.org>; Fri,  8 Aug 2014 08:36:02 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
 (PMDF V6.1-1 #35243) id <01PB4QVGJQKW000OMW@mauve.mrochek.com> for
 abnf-discuss@ietf.org; Fri, 8 Aug 2014 08:30:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve;
 t=1407511871; bh=N7aAR/TVD89ybyubh9uiCVU1uL4jV3Cc23s/vPrmQ0c=;
 h=Cc:Date:From:Subject:In-reply-to:References:To;
 b=nqaOs4rf4PAJVqO3ZOkeEW5/clgW/eiX1g7g9Ws2aaVpR+DfSguHNOvSrN2ORIYqD
 jG1JIc7ha0+uehSO46ezKp6D4A9n49CivT9L47G3572GvgCTNS6Rq3wDGfEl8kJUNG
 KOvReir5AbJUi04LK1nKJ7uMPEeiQTO9lc9OdRQ8=
MIME-version: 1.0
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01PB2RFWCBO00000SM@mauve.mrochek.com>; Fri,
 08 Aug 2014 08:30:56 -0700 (PDT)
Message-id: <01PB4QVEXI220000SM@mauve.mrochek.com>
Date: Fri, 08 Aug 2014 08:24:57 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 08 Aug 2014 13:49:24 +0000"
 <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>
 <0EFEDBFE-D322-4DB4-A5AC-CBDBA49D5118@cisco.com>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/abnf-discuss/ZZbjfp6yaxRtNo972l5wwGWgFHo
Cc: Ned Freed <ned.freed@mrochek.com>,
 "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.

That could have been done trivially by saying that the symbols the ABNF
is dealing with aren't octets but rather unicode characters, and extending
ABNF for this one RFC to allow decimal constants outside the ASCII range.

Not seeing a reason here for putting a bunch of gorp in ABNF. Indeed, the
multiple encoding side of this seems to me to be a compelling reason not to.

Now, I suppose you could argue that we could or should standardize a means
of representing that the base symbol set of ABNF has been extended to the
unicode repetoire. I'll buy the need for that the minute two RFCs do it.

				Ned


> 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.

Why wouldn't the approach I mentioned have worked?

				Ned

> 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