Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

Ladislav Lhotka <lhotka@nic.cz> Wed, 06 September 2017 07:27 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77341321D5 for <netmod@ietfa.amsl.com>; Wed, 6 Sep 2017 00:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 7-z1auz5ir44 for <netmod@ietfa.amsl.com>; Wed, 6 Sep 2017 00:27:51 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0285C127005 for <netmod@ietf.org>; Wed, 6 Sep 2017 00:27:51 -0700 (PDT)
Received: from birdie106 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 2408C60B35; Wed, 6 Sep 2017 09:27:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504682869; bh=f/qbwXwc1LuIW/e3ARI4vh7uk9U4HH/hlz9T68OHkyU=; h=From:To:Date; b=d1xgyjxXDadDS48Rgi17HYwofuiJl08BYJMrvNCNBGRoMeMU8kwL911MOYKGAzckh z1b/nTMn12uLUOiF9eWyl7cK26JnoCQVN1/J5TjPbPrNzrShDclKTiGiB5hvuYIQDB J1+jkQwfP0U5pa1067Q14kVCY0ruucWsxYEzzCF4=
Message-ID: <1504682901.3468.5.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Robert Wilton <rwilton@cisco.com>
Cc: netmod@ietf.org
Date: Wed, 06 Sep 2017 09:28:21 +0200
In-Reply-To: <20170905180006.yecbqqdhxtkvosxk@elstar.local>
References: <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <D5D00209.C5C67%acee@cisco.com> <20170902112832.ymorfgdthobeio6q@elstar.local> <CABCOCHTC2MhBu0Zu44Z=f+J04HiENjQR+J0Sxy-arjcDmBHb_A@mail.gmail.com> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <f0ddf7bd-c249-389f-e34b-0b901697307e@cisco.com> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <20170905180006.yecbqqdhxtkvosxk@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/qkZHS2DpnbqKdPUOKz4rM_G2T50>
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2017 07:27:53 -0000

Juergen Schoenwaelder píše v Út 05. 09. 2017 v 20:00 +0200:
> On Tue, Sep 05, 2017 at 06:17:09PM +0100, Robert Wilton wrote:
> > 
> > > I believe that tools intended for general use should follow the YANG spec
> > > literally.
> > 
> > I don't fully agree.  I think that they only need to cover the parts of the
> > YANG spec for the models that they are using (or might use). If nobody uses
> > Unicode blocks then it doesn't really matter whether a given tool supports
> > them or not.  It is always possible to caveat and add support for the
> > missing bits later.  E.g. if I was writing a bespoke XPATH implementation
> > for YANG then there is probably quite a lot of the XPATH spec that I would
> > also leave out as well, and just concentrate on the parts that people
> > actually use, or are likely to use.
> > 
> 
> If this is your understanding of standards, why do you want to define
> a subset of XSD pattern based on the your observation what is used or
> not used? Simply do not implement what you observe is not used. Why do
> we need guidelines of constructs not to use so that they are not used?

Agreed. Also, XPath is different: due to the restrictions imposed on data trees
modelled with YANG compared to general XML (no mixed content, no document order)
som XPath features don't make sense by definition. This is not the case for
Unicode strings.

Lada

> 
> There are multiple contradictions in your posts, one of them was the
> idea of translating unicode matching to ASCII - which simply does not
> work. Or the post where you said \d is OK but then later said \d is
> not OK since it translates to a large number of numeric characters.
> You really need to sort out what you want, what the problem is you are
> trying to solve, how you select the subset of XSD pattern etc. Write
> and I-D. And at the end, people who only do POSIX regular expressions,
> because they come with the standard C library on POSIX systems or
> whatever the reason really is, still will either have to continue to
> cheat by silently interpreting XSD pattern as POSIX pattern or they
> create a proper new statement to at least properly distinguish
> different pattern languages.
> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67