json-schema-vocabularies
json-schema-vocabularies copied to clipboard
json-schema-org
Add Defined Format: MAC Address
Proposal: Add a defined format for Mac Address. The schema already has support for IPv4 and IPv6 data types. It would be useful to have support for the colon delimited MAC address format in the base schema.
Something similar to the following:
"mac_address": {
"type": "string",
"description": "Represents a MAC Address in the standard colon delimited format. Eg. `01:23:45:67:89:0A`",
"pattern": "^([A-F0-9]{2}:){5}[A-F0-9]{2}$"
}
I can see an argument for this on the grounds of fitting in with network address formats in general.
I can see an argument against this on the grounds that it's not as common as IP addresses, and it's also not hard to validate with a regexp (unlike, say, IPv6 addresses which can technically be validated with a regexp but the regexp is excessively long and complicated).
Let's leave this open and give more folks a chance to weigh in.
Thanks, I work for a networking company so they float through our API's a lot. I guess that it makes sense that it isn't all that common in the rest of the industry.
Not sure if pre-defined patterns should be within the spec at all thought because you'll end up cherry picking. Today's "common" patterns may be of no use tomorrow but the spec is there to potentially stay for a long time. I indeed also would need a MAC validator in my current project but for the spec I think it would be not a good thing to add.
There's no reason you can't add a regex for this in your schema, and then use allOf and $ref to validate.
Personally, given recent discussion and potential direction, I'm leaning towards thinking we shouldn't have IPv4 or v6 format... format is a bit of a mess =/
(Based upon a previous discussion with @handrews around I18N) I would be a fan of separating out related formats into their own "modules", in order that an implementation can choose to actively support a set of formats.
Existing RFCs and drafts might suggest natural groupings for formats. For example, the IETF inet types YANG module specifies many of the same formats as in the validation draft.
Given that we (in other issues) decided that "duration" and "uuid" would make sense for now, I think it's sensible to add in "mac-address".
As @Relequestual notes, format is a mess and needs a lot of attention, but I think this isn't making that situation much worse. The problems with format (and to a lesser degree, content*) will be a major focus of the draft after the one we're about to publish.
OK on further investigation, I don't have access to IEEE docs, and I can't figure out what to cite here. It also seems like the formats should really be "eui-48" and "eui-64". @JLLeitschuh or anyone- advice on this? If this turns out to be straightforward we can put it in the about-to-be-published draft, if not we can deal with it when we do more clean-up on format.
I'm really not sure what to do about this and don't have the bandwidth to sort it out before publication. Bumping to the next draft unless someone shows up with an obvious way forward.
Note to myself: Pydantic is adding support for generating JSON Schema for IP addresses using custom format attribute values of:
ipv4addressipv6addressipvanyaddressipv4interfaceipv6interfaceipv4networkipv6network
The work is being done in this PR: https://github.com/samuelcolvin/pydantic/pull/532
If later there's an official, spec-defined format for IP addresses, networks, MACs, etc, we (I) should update Pydantic to use the newly adopted official format.
@tiangolo there are already ipv4 and ipv6 formats. This issue really just needs someone who can figure out how much we need to worry about different MAC address formats. It only got bumped out b/c I don't have time to research that myself (the spec is like 6 months late as it is)
Not sure if pre-defined patterns should be within the spec at all thought because you'll end up cherry picking. Today's "common" patterns may be of no use tomorrow but the spec is there to potentially stay for a long time. I indeed also would need a MAC validator in my current project but for the spec I think it would be not a good thing to add.
MAC addresses have now been in use for 42 continuous years and are not going away anytime soon. They will exist longer than IPv4 will. There is no effort nor interest in an Ethernet III spec. The accelerating adoption of IPv6 overshadows any sort of retro-adoption of MAC-centric inter-routing (e.g. IPX) which would drive a change and major revision for Ethernet. The use of MACs is pervasive, including wired Ethernet, wireless WiFi, and cellular LTE.
The MAC address format is six two-digit hexadecimal fragments, zero-prefixed and separated by colons. The use of hyphens is rare and an anomaly. Requiring the app developers to replace hyphens with colons for those rare cases should be acceptable though accepting one or the other would be fine. Mixing them would not be.
Both upper and lower case letters are used in different systems and use-cases. My suggestion would be to allow the user to set all-lower or all-upper for output, defaulting to upper, and allow any-case on input. MAC addresses are fundamentally a positive integer, not a string, similar to IP addresses. They are six bytes programmed into PROM or flash on the NICs (ignoring virtual devices which would then just be in RAM).
If you want to get fancy, MACs have a prefix that is assigned to vendors and then the vendor generates the lower half. It is possible to ID the vendor (or "OUI" in MAC-speak) from the MAC. See https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd3e4 or OG https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries Though I think that part may be best left to the app developers.
The 802.x networking specs have been sponsored and are currently available free-of-charge. https://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68
We are no longer adding formats. The correct approach is to create an extension vocabulary for this (and, we hope, for the existing formats, although of course those need not be all done by the same people or project). Extension vocabularies that prove popular might be adopted into the spec in the future.
I am moving this to the vocabularies repo, which ideas for extensions are held.