Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-00.txt

From: [email-masked]
Date: Mon, 15 Apr 2019 11:54:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Common YANG Data Types
        Author          : Juergen Schoenwaelder
	Filename        : draft-ietf-netmod-rfc6991-bis-00.txt
	Pages           : 44
	Date            : 2019-04-14

Abstract:
   This document introduces a collection of common data types to be used
   with the YANG data modeling language.  This document obsoletes RFC
   6991.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6991-bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kent Watsen <[email-masked]>
Date: Thu, 18 Apr 2019 04:51:21 +0000

Many times in models I want a non-empty version of what XSD calls a "token":

    token    A string that does not contain line feeds,
             carriage returns, tabs, leading or trailing
             spaces, or multiple spaces.

So how about the following?

  typedef token {
      type string;
      length "1.max";         // non-empty (some expr do this already)
      pattern "[^\n\r\t"]+"   // no LFs, CRs, or Tabs
      pattern "[^ ].*";       // no leading space     (min-length 1?)
      pattern ".*[^ ]";       // no trailing space    (min-length 1?)
      pattern ".*[^ ][^ ].*"  // no multiple spaces   (min-length 2?)
  }

Kent // contributor

---

From: William Lupton <[email-masked]>
Date: Thu, 18 Apr 2019 14:23:30 +0100

Does the last pattern work? I think it matches any string with two
consecutive non-spaces, e.g. "AA  AA" ("AA" + two-spaces + "AA").

To prevent multiple spaces I think we probably need something like "([^ ]+
)*[^ ]+" (which replaces the last three patterns).

Do XML regexes support \S (not-whitespace)? If so then I think that "(\S+
)*\S+" covers everything (although also excludes FF and any other
whitespace characters if there are any).

On Thu, 18 Apr 2019 at 05:51, Kent Watsen <[email-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 18 Apr 2019 15:28:43 +0200

William, Kent,

> Does the last pattern work? I think it matches any string with two consecutive non-spaces, e.g. "AA  AA" ("AA" + two-spaces + "AA").
> 
> To prevent multiple spaces I think we probably need something like "([^ ]+ )*[^ ]+" (which replaces the last three patterns).
> 
> Do XML regexes support \S (not-whitespace)? If so then I think that "(\S+ )*\S+" covers everything (although also excludes FF and any other whitespace characters if there are any).

William is right in his observation. I had on my todo list to point this out, but I got side tracked :)
An easy way to express this in YANG (1.1) is:

// reject values with two consecutive spaces
pattern "  " { // two spaces
  modifier invert-match;
}

/jan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 21 Apr 2019 16:40:28 +0200

Kent,

can you provide examples where this particular type is useful? Or were
you generally looking for a type to name things and the XSD token type
was the first one that came your mind?

If the goal is to define a type for identifiers, then we likely should
follow the Unicode standard annex UAX-31 and make use of <XID_Start>
<XID_Continue>, which is what I think Python3 and Rust are using as
the basis for their notion of language identifiers (but then the
Unicode definitions are also criticized as buggy). A challenge is that
the definition of <XID_Start> and <XID_Continue> seems to evolve with
the unicode version. And once you start digging into the various
attempts of modern programming languages to support internationalized
identifiers, you discover that this is far from trivial to get right.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 22 Apr 2019 20:20:48 +0000

Hi Juergen,

> can you provide examples where this particular type is useful?

Useful in many contexts.  For instance:

    list user {
      key name;
      leaf name {
        type string;
      }
      leaf password {
        type string;
      }

The following instance document is valid:

  <user>
    <name/>
    <password/>
  </user>

Adding pattern statements works, but gets old after awhile.  A built-in type would be helpful.

> Or were

Yes, from past-life experience with XSD, I found "token" and "normalizedString" useful (https://www.w3schools.com/XML/schema_dtypes_string.asp <https://www.w3schools.com/XML/schema_dtypes_string.asp>).   However, those types
do not fully express what I really want (including, e.g., non-empty), which is:

a) a type for a non-empty, stripped, printable string that MAY contain internal 'space' characters.

b) a type for a non-empty, stripped, printable string that MAY NOT contain internal 'space' characters.

/kw

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Apr 2019 18:43:23 -0700

> Useful in many contexts.  For instance:

Why would type string be used?

    list user {
      key name;
      leaf name {
        type yang:yang-identifier;
      }
      leaf password {
        type iana:crypt-hash;
      }
  }

Still not clear on the use-cases for a token data type.

Andy

> Yes, from past-life experience with XSD, I found "token" and
> "normalizedString" useful (
> https://www.w3schools.com/XML/schema_dtypes_string.asp).   However, those
> types

---

From: Kent Watsen <[email-masked]>
Date: Tue, 23 Apr 2019 02:12:48 +0000

yang-identifier is not appropriate.

Ignore the password, it's not the important (e.g., passwords can have spaces at the beginning or end).

K.

> On Apr 22, 2019, at 9:43 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Mon, Apr 22, 2019 at 1:21 PM Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Juergen,
> 
> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>> 
>> -- 
>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>