Talk:Parse an IP Address: Difference between revisions
(→Sloppy: Not necessarily sloppy, but complex.) |
(→Sloppy) |
||
| Line 19: | Line 19: | ||
But I am not sure which way to go here. --[[User:Rdm|Rdm]] 13:58, 28 September 2011 (UTC) |
But I am not sure which way to go here. --[[User:Rdm|Rdm]] 13:58, 28 September 2011 (UTC) |
||
: The trouble is, connection targets (IP/port combinations) are frequently passed around in ''string'' format with the version undeclared. Many programs which need to operate with IPv4 and IPv6 addresses actually have difficulty with it, even though the standardized formats are documented. Correctly converting that string representation into a logical representation is what this task is intended to be about. The inclusion of both IPv4 and IPv6 notation, as well as the inclusion ":portNumber", is intentional, to attempt reflect the full complexity of the problem. So what remains is likely a poorly chosen task title and an an insufficiently-described task. I have extreme difficulty being clear on the latter point, though. --[[User:Short Circuit|Michael Mol]] 14:27, 28 September 2011 (UTC) |
: The trouble is, connection targets (IP/port combinations) are frequently passed around in ''string'' format with the version undeclared. Many programs which need to operate with IPv4 and IPv6 addresses actually have difficulty with it, even though the standardized formats are documented. Correctly converting that string representation into a logical representation is what this task is intended to be about. The inclusion of both IPv4 and IPv6 notation, as well as the inclusion ":portNumber", is intentional, to attempt reflect the full complexity of the problem. So what remains is likely a poorly chosen task title and an an insufficiently-described task. I have extreme difficulty being clear on the latter point, though. --[[User:Short Circuit|Michael Mol]] 14:27, 28 September 2011 (UTC) |
||
:: The string format is unambiguous. But result format is ambiguous, here. --[[User:Rdm|Rdm]] |
|||
Revision as of 15:02, 28 September 2011
Hm. I'm thinking the decimal number requirement isn't necessary. Removing. --Michael Mol 12:35, 27 September 2011 (UTC)
Sloppy
This task currently seems sloppy.
First, it requires that extra data (the port) be ignored. In practical use, if the port is being passed to a routine that parses ip addresses, this probably means the data is being mishandled. So good practice suggests that this be treated as an error case. This is a minor but annoying complexity in the task.
Second, it asks us to mix ipv4 and ipv6 addresses but ipv4 addresses have a representation as ipv6 addresses (see rfc 2373, for example) but the example implementation mixes them in the same data structure without labeling the type and without using a consistent mapping.
I can think of several ways to go here:
- Discard the port parsing requirement
- Ask for ip,port to be reported as a pair
- Ask for ipv4 and ipv6 address results to be distinguished (or put them in separate tasks)
- Ask for the ipv4 addresses to be encoded as ipv6 addresses (127.0.0.1 becomes ::127.0.0.1 to distinguish it from ::7f00:1).
- change the task to make some of these issues moot
But I am not sure which way to go here. --Rdm 13:58, 28 September 2011 (UTC)
- The trouble is, connection targets (IP/port combinations) are frequently passed around in string format with the version undeclared. Many programs which need to operate with IPv4 and IPv6 addresses actually have difficulty with it, even though the standardized formats are documented. Correctly converting that string representation into a logical representation is what this task is intended to be about. The inclusion of both IPv4 and IPv6 notation, as well as the inclusion ":portNumber", is intentional, to attempt reflect the full complexity of the problem. So what remains is likely a poorly chosen task title and an an insufficiently-described task. I have extreme difficulty being clear on the latter point, though. --Michael Mol 14:27, 28 September 2011 (UTC)
- The string format is unambiguous. But result format is ambiguous, here. --Rdm