On 5/5/22 11:05, Carsten Bormann wrote: >>>> * Would it make sense to further refine your contact leafs to check for >>>> the MUST URI schemas? > (They are URI schemes, not URI schemas.) > > It is generally a mistake to hardwire specific URI schemes in a specification > that uses URIs to provide flexibility. > (What if in a few years you would want to use a newly popular instant > messaging URI scheme for contacting people?)
This is a fair point. "tel" may be "holo" in the future... > > But let me go with the program. > >>> I know what you want, but I'm not quite sure it is well specified how to do >>> it. Patterns in general seem underspecified. If someone can explain how >>> to do it, I'm happy to add. > I’m not sure whether you are saying YANG patterns are underspecified: They > are not. > > https://www.rfc-editor.org/rfc/rfc7950.html#section-9.4.5 > > If you want to know more about the type of regexp that is being used there, > you may want to check > > https://www.ietf.org/archive/id/draft-ietf-jsonpath-iregexp-00.html#name-xsd-regexps > > (Section 5 tells you how to map the iregexp subset into regexp dialects you > may be more familiar with. > While iregexps restrict the regexps a little further than YANG does, the > iregexp subset is usually what you actually need and also is essentially the > subset that actually works the way many people would think they do. > If you see a non-iregexp YANG pattern, I’ll bet you a beer that this is > actually broken [1].) > >> I can't recall having seen this done before, > (Maybe because premature restriction of the schemes is, after all, not such a > bright thing to do?) Indeed, but the normative language is there already, the typedef says it's allowed, and I thought it might be better to also codify this. > >> but I was thinking along the lines of: >> >> type inet:uri { >> pattern "(mailto)|(https?)|(tel):.*"; >> } > Wrong precedence; I think you want > >> pattern "(mailto|https?|tel):.*"; Yes, sorry. Joe _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
