Just to bring to the attention of the mailing list: the change above needs to
be reverted.
The change tried to implement parsing of MAC addresses in URIs, in the form:
<scheme> "://" <1-12 * hexdig>
Examples:
coap+bt://001060319bb1
coap+bt://001122334455
Here's the problem: any MAC address not containing the hex digits "a" through
"f" (like 001122334455) are valid IPv4 addresses parsing under legacy parsing.
For example, 017700000001 (exactly 12 digits long) is the same as 127.0.0.1
and thus cannot be used to represent MAC address 01:77:00:00:00:01. Proof:
$ curl -v http://017700000001
* Rebuilt URL to: http://017700000001/
* Trying 127.0.0.1...
* connect to 127.0.0.1 port 80 failed: Connection refused
* Failed to connect to 017700000001 port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 017700000001 port 80: Connection refused
Or try loading http://3627735214 or http://030644216524 on your web browsers
(you should see the Google and the LF Collab Projects homepage, respectively).
True, IoTivity does not accept such addresses and RFC 3986 does not allow for
them either. However, since they are in wide use out there, we should not
reuse the syntax as other implementations of URL parsing may be unable to
cope.
Suggested alternatives:
1) append an alphanumeric domain suffix, such as:
coap+bt://017700000001.m/
coap+bt://017700000001.mac-address/
coap+bt://017700000001.mac.arpa/
coap+bt://01.77.00.00.00.01.mac.arpa/
coap+bt://01.00.00.00.77.01.mac.arpa/ (reversed)
Drawbacks:
* the suffix we choose is not defined and is not reserved by IANA, so it
could get used in the future. Unless, of course, we publish an RFC defining
it.
Advantages:
* simplest to parse
2) store the address as IPv6:
coap+bt://[::177:0:1] (no transformation, not recommended)
coap+bt://[::177:ff:fe00:1] (with expansion to EUI-64)
coap+bt://[::377:ff:fe00:1] (with expansion to Modified EUI-64)
coap+bt://[fe80::<EUI-64 or Modified EUI-64>] (as link-local)
coap+bt://[fe81::<EUI-64 or Modified EUI-64>] (link-local
unused)
Drawbacks:
* without the link-local prefix or the EUI-64 conversion, certain MAC
addresses would fall into the IPv4-compat address range
* even with the conversion to EUI-64, certain MAC addresses could be parsed as
IPv4-mapped (if they are of the form 00:00:FF:xx:xx:xx and that OUI is
assigned)
* more complex to parse
* requires out-of-band information to indicate that this is a MAC address as
opposed to an address reachable using the IPv6 stack (the "coap+bt" scheme)
Advantages:
* syntax is known and RFC 6874 updates to include the Zone ID, which MAC
addresses might need like IPv6 link local ones do.
3) store the address as IPvFuture:
coap+bt://[v0.017700000001]/
coap+bt://[v0.01.77.00.00.00.01]/
coap+bt://[v0.01:77:00:00:00:01]/
Drawbacks:
* IPvFuture version 0 is obviously not standardised and is not even IP
* Many implementations may have defective or lacking altogether parsing of
IPvFuture, as no one uses it
Advantages:
* Can't think of any
4) Store elsewhere in the URI
a) in the query
coap+bt:/?mac=017700000001
Disadvantages:
* requires more complex parsing and considerable refactoring of our code
* may collide with other query values
b) in the userinfo:
coap+bt://017700000001@/
coap+bt://017700000001 at mac.arpa/
Disadvantages:
* same as the TLD issues in case #1
* the userinfo may be required in other contexts
c) in the scheme:
coap+bt-017700000001:/
Disadvantages:
* awkward parsing and handling, since it requires breaking down a component
after parsing
My recommendation:
i) if the "coap+bt" scheme is sufficient context, I prefer IPv6 style with
expansion to EUI-64 and with a suitable prefix
ii) if it is not sufficient context, then instead I'd opt for the ".mac.arpa"
suffix and for writing an RFC reserving it with IANA
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
