Open rohanmahy opened 3 weeks ago
RFC 9164 (tags 54 and 52) supports zone-IDs in the Interface format (section 3.1.3) only. I'm not sure the 3986/6874 combo is good guidance for how Interface format IP addresses should be represented.
Section 2.2 already says:
Note that there is no direct representation of an address combined
with a prefix length; this can be represented as
52([ip'192.0.2.42',24]), if needed.
In the tradition of messing up everything with zone identifiers, the CDDL for ip-zone-identifier in RFC 9164 is not consistent with the example in Section 3.2.
I'd rather stay out of the zone identifier quicksand until it settles.
Hi, proposed a change to PR#63 that addresses my concern:
"If we don't want 'IP' to support zone IDs I think we should explicitly mention that in the draft."
(This was auto-closed as a result of merging #63 as a basis for an editorial attempt.) As the discussion is not yet completed (https://github.com/cbor-wg/edn-literal/pull/63#discussion_r1727104056), this issue is reopened.
See also the thread under Archived-At: https://mailarchive.ietf.org/arch/msg/cbor/oTnpnDt-Rl4K51L-OeLJ2LgEIDQ
RFC6874 extends IP-literal URIs to support IPv6 zone IDs. the 'IP' app-string defines a bare address with an optional subnet mask (app-string-ip as IPaddress plus an optional slash and mask). IPaddress includes a regular IPv4 or IPv6 address but does not include IPv6 addresses with a zone ID:
fe80::bd0f:a8bc:6480:2389%en1
while there is no direct representation of a zone ID for a lower case 'ip', the IPv6 tagged array (tag 54) could be extended to include the zone ID with 'IP':
`54([128,h'fe80 0000 0000 0000 bd0f a8bc 6480 238b', "en1"])
If we don't want 'IP' to support zone IDs I think we should explicitly mention that in the draft.