Open ektrah opened 5 years ago
$ ping 0015105550101
PING 0015105550101 (105.22.208.65) 56(84) bytes of data
(The tel
URIs are unaffected by this because URN capable parsers do not fall into the pitfalls URL parsers sometimes have implemented.)
Expressing telephone numbers as E164 addersses (1.0.1.0.5.5.5.0.1.5.1.e164.arpa
) has worse readability and verbosity, but work well with whatever expects host names. RFC3986: "URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length".
We could encode the telephone number in the lower bits of an IPv6 address and convert those to octal 😈
ABCD:EF::6916:D041 → 0x6916D041 → 0o15105550101 → +15105550101
An E.164 address never starts with a zero.
Leading zeros or not, even if we used E164 addresses (coap+sms://15105550101/path
with the semantics of 15105550101 defined by E164) danger that URI handlers interpret RFC3986's "first-match-wins" rules in terms of "whatever my inet_aton
accepts".
Whether that danger warrants using the DNS-ish notation is a different question.
An E.164 address never starts with a zero.
"00" is the IDD prefix that the ITU recommends, although I cannot ascertain how many countries conform to it. On the other hand, there may be even fewer countries implementing .e164.arpa !
The current LWM2M Spec uses the MSISDN number for the SMS binding.
We need to check how URI parsers in common programming languages react to the
coap+sms://
URI scheme.E.g.,
coap+sms://0015105550101/sensors/temperature
might be problematic, because0015105550101
might be interpreted as the (non-dotted, octal form of the) IPv4 address105.22.208.65
by some URI parsers. (This is one of those places where implementations deviate a lot from the spec...)