[YANGTOOLS-576] Introduce canonical-pattern extension Created: 25/Jan/16 Updated: 12/Jun/18 Resolved: 12/Jun/18 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | codecs, parser |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | ||
| Reporter: | Tony Tkacik | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Description |
|
Introduce cannonical-format extension to describe pattern of cannonical value of string and provide enforcement tools |
| Comments |
| Comment by Abbas P Pareedkunju [ 20/May/16 ] |
|
Hi Tony, I would like to work on this concern you have raised. Would you be please able to give some more details on what you are looking for? Thanks, |
| Comment by Abbas P Pareedkunju [ 31/May/16 ] |
|
really appreciate any more details. |
| Comment by Robert Varga [ 07/Sep/16 ] |
|
To clarify a bit. RFC6020 has the pattern restriction, which defines how an allowed value must look like – allowing for multiple representations. This is evident in ietf-inet-types, where IPv6 and MAC addresses can have both capitalized and non-capitalized letters. Unfortunately YANG does not define a mechanism to define what the canonical format looks like, e.g. lower-case letters in MAC. Hence we need to define an extension, canonical-pattern, which will take a single argument, just like pattern does and can be applied only once in a type hierarchy. |
| Comment by Robert Varga [ 12/Jun/18 ] |
|
We don't really need this, as in 3.0.0 we will actually use specialized value classes to support canonical representation – with conversion and storage. |