Unlike in boost::asio::ip::address_v6

I'm trying to implement this thing but what asio supports is an extra std::uint32_t in the ipv6 address to store the scope_id while what URLs in RFC6874 support is an extra Zone ID of any size in front of the IPv6:

      IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"
      ZoneID = 1*( unreserved / pct-encoded )
      IPv6addrz = IPv6address "%25" ZoneID

The problem is there's no deterministic relationship between the two. The mapping from the Zone ID and the 32-bit scope_id is obtained from an operating system API that maps the zone string to its corresponding numeric value.

So we can include the same scope_id overloads in our ipv6address but there's no way to determine this value from the ZoneID string. Or we can just store the ZoneID in ipv6address and not deal with the conversion but that would imply ipv6address carrying a whole std::string or, even worse, ipv6address and ipv6address_view variants.

Another option is just accepting the ZoneID as valid input but not changing anything in ipv6address: it would just store the addresses and have a scope_id field that can be set but it's always zero by default.

boost::urls::ipv6_address does not support scope id #711

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions