Robert Wilton píše v St 23. 08. 2017 v 17:58 +0100: > > On 23/08/2017 15:22, Ladislav Lhotka wrote: > > Juergen Schoenwaelder píše v St 23. 08. 2017 v 15:36 +0200: > > > On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote: > > > > 1) Email address. I understand that the full regex to validate all > > > > email > > > > addresses is very complex, but checking that it at least contains an @ > > > > symbol still has benefit. It would seem that a short imperfect regex is > > > > better than a complete perfect regex. > > > > > > What is your definition of 'better'? A stricter pattern catches more > > > errors. An imperfect pattern is better than none. > > > > > > > 2) A list of VLAN ranges, e.g. want to allow strings that look like > > > > this: > > > > "1-10,20-400,600,2000-3000", but only with non overlapping values in > > > > ascending order. It is easy to write a regex to check that the > > > > structure is > > > > right, but AFAIK it is hard (impossible?) to write a regex that ensures > > > > that > > > > the ranges don't overlap and are specified in ascending order. > > > > > > So what. Does this provide a helpful argument whether patterns should > > > be strict or imperfect? > > > > > > > So, I propose that we use regexes for checking that the string is > > > > structurally correct, but don't use regexes to perform numerical range > > > > checks of string encoded numbers, since it makes the regexes hard to > > > > read/verify, and doesn't improve the readability of the YANG file > > > > either. > > > > > > So here is the point I think: > > > > > > It is desirable that regexes are as strict as they can be. > > > However, if regexes become so complicated that they become a > > > verification and maintenance problem by themself, then less strict > > > regexes may be a better choice. > > > > Either way, the regex must not produce false negatives, i.e. reject valid > > values. For some regexes this is what makes them complicated. > > I agree. > > > > > Also, I don't see any need for replacing existing patterns unless they are > > wrong. > > I also agree. I'm not trying to retroactively change existing regexes, > just tweak the guidance when new regexes are being constructed so that > they end up being a bit simpler.
This is really subjective, and I am certainly on the side of making the regexes as strict as possible because they guard not only against typos but also against intentionally invalid values, i.e. attacks. Lada > > Thanks, > Rob > > > > We have descriptions to tell human readers about the permitted value set. > > > > Lada > > > > > /js > > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
