Freek Dijkstra added the comment: Peter, first of all, thanks for your library. I didn't mention that before, but should have.
I'm in favour of a pragmatic approach. I've only come across NATing for RFC 1918 and RFC 6598 addresses. While it can technically be done for other addresses, and is allowed by RFC 3022 section 5.1, I have never seen that in practice. is_natted() (or perhaps: is_nattable()?) could be used by a SIP client to decide if it should include a VIA header or not, without need to do a resource-expensive NAT check at all times. To be clear: I'm not a great fan of is_natted() myself, but I fear that keeping is_private() the way it is, people will use it as if it meant is_natted() and will end up with unintended errors in their code. is_forward and is_global -if deemed useful- should just follow the columns at http://www.iana.org/assignments/iana-ipv4-special-registry and http://www.iana.org/assignments/iana-ipv6-special-registry. Perhaps functions like is_valid_source(), is_valid_destination() and is_reserved() may be included too. The meaning of these columns is explained in [http://tools.ietf.org/html/rfc6890#section-2.2.1 RFC 6890]. I interpret forwardable as "should be forwarded by a router" and global as "may be seen on the Internet / should be forwarded beyond administrative domain boundaries". For example, private IP addresses or benchmarking IP addresses may be routed just fine, as long as they're never seen on the global Internet. PS: There is a typo in the documentation. is_unspecified mentions RFC 5375, but that should be RFC 5735, which in turn is obsoleted by RFC 6890. I'll see if I can make a patch, but that will be after my holiday. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17400> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
