[Cbor] Tag 35

[Carsten Bormann <[e-mail]>]

3.4.5.3 of the current draft says:

   *  Tag number 35 is for regular expressions that are roughly in Perl
      Compatible Regular Expressions (PCRE/PCRE2) form [PCRE] or a
      version of the JavaScript regular expression syntax [ECMA262].
      (Note that more specific identification may be necessary if the
      actual version of the specification underlying the regular
      expression, or more than just the text of the regular expression
      itself, need to be conveyed.)  Any contained string value is
      valid.

Ben wrote (DISCUSS):

> Let's discuss whether the framing of tag number 35 for "regular
> expressions that are roughly in [PCRE] form or a version of the
> JavaScript regular expression syntax" meets the interoperability
> expectations for Internet Standard status (bearing in mind that we are
> defining a data format and not a protocol).  I note that it is okay
> to leave the codepoint allocated with the current meaning and the
> previous document as its reference, but decline to discuss it in the
> document going for STD (we are in the process of doing that with COSE
> countersignatures at the moment).

Roman wrote (COMMENTS):

** Section 3.4.5.3.  For Tag 35, how does one know if the syntax is a PCRE or
ECMA regular expression?

** Section 3.4.5.3.  PCRE is the only informative reference of all of the tags
defined in this section (even ECMA is normative).  Please make it normative.


In summary, there are two problems here:

— Tag 35 stands for mix of PCRE (actually, PCRE and PCRE2) and ES20xx regular expressions.
— There is no good reference for PCRE.

What could we do?

1. Delete Tag 35 from RFC 7049bis.  This creates the awkward situation that the registry will contain a tag with a reference to an obsoleted document; or we would need to eschew obsoleting RFC 7049 (which would confuse the heck out of everybody).

2. Keep Tag 35 in RFC 7049bis, and make the PCRE reference (which is really to a web page that is changing occasionally) normative.  We would still not actually say which of the formats (PCRE, PCRE2, ES20xx, and in which version) is actually in the tag content, and would probably need to strengthen the language saying that.

2a.  Do the same and make clear that one only gets interoperability by keeping to the common subset of all these Perl-5-derived formats.

3. Keep Tag 35 and make the references to PCRE and ECMA262 informative (ECMA262 is referenced in another place, but that also is informative).  Not clear how to pull this off, but probably needs 2a as a prerequisite.


Note that EcmaScript since version 3 (1999), where regexes where introduced, contains this note:

> The form and functionality of regular expressions is modelled after the regular expression facility in the Perl 5 programming language.

Since we are transporting regular expressions, not regular expression literals (i.e., with slashes around them) in a specific lamguage, we cannot even transport  the flags bits, so we don’t touch areas of major deviations such as the “s” flag.

We are not really in the business of defining regular expressions (and XKCD 927), so the solution found in RFC 2915 (simply specify another dialect) does not really apply.

When I have used tag 35 (not in any shipped protocols, I think), I stuck to a basic subset; e.g., it is not very likely that different implementations will differ in interpreting “^[A-Za-z][A-Za-z0-9]*$” (note the need to anchor the regex, and the need to eschew \A and \z for that).

Grüße, Carsten