Replace OPAQUE_INFO by NEARBY_VS in EAD_1

[geonnave]

This is a sketch towards issue #23.

Still not sure how to handle the possible representations of network identifiers listed in the table. For example: should MAC Addresses be sent only as bytes? And what about IPv6 address, should it always be 128 bits or also support compressed notation? (I think we don't want to over-engineer this).

[mcr]

RFC9164 for IPv6 maybe.

[geonnave]

RFC9164 for IPv6

Thanks, I think we should use it.

I was also not aware of the CBOR tags registry, which has definitions for MAC Addresses.

I think for sure we want to re-use the tag numbers, but I am not sure if we keep the semantics of the data items, considering that we will likely have a list of nearby_vs / hints, thus leading to duplication of tag values, which is not ideal given the constrained link between U and V.

For this we could define a special encoding just to save bytes (similar to specific encodings found in EDHOC, e.g. when single-element uint arrays are encoded as just uint). For example we could:

1. just tag a whole array, and all elements will have the same meaning
2. put the tag as first element in the array

The advantage of (1) is using the tag as a proper tag, but the disadvantage is that the change in semantics of the data item might be misleading.
As for (2), it does not cause confusion with tag semantics, but it feels a bit hacky.

[geonnave]

Just to clarify, I don't think of changing the representation of the identifiers, just how they are grouped with respect to a given tag.

[geonnave]

Closing as obsolete, as result of discussions over privacy (#27) and after merging of #41.