Talk:Parse an IP Address: Difference between revisions

m
fixed an HTML tag.
m (fixed an HTML tag.)
 
(10 intermediate revisions by 4 users not shown)
Line 1:
==IP address in decimal==
Hm. I'm thinking the decimal number requirement isn't necessary. Removing. --[[User:Short Circuit|Michael Mol]] 12:35, 27 September 2011 (UTC)
 
: Yes, in all my many years, I've never seen a complete (full) IP address in decimal: it's either in hex or dotted decimal: <tt> w.x.y.z </tt>
: I only included the decimal version of an IP address (for the REXX language) because it was shown in decimal a couple of places in the task description. -- [[User:Gerard Schildberger|Gerard Schildberger]] 14:45, 23 April 2012 (UTC)
 
== Sloppy ==
Line 22 ⟶ 26:
:: The string format is unambiguous. But result format is ambiguous, here. --[[User:Rdm|Rdm]]
::: Ah, I see now. I only saw the output format of the task to be relevant in that it required comprehension of the input format to generate. The internal representation (in particular, correct distinction of host and port addresses) was what I was more interested in. Requiring the port address in the output helps a reviewer understand how the port number was understood. Change the requirements for the output format however you see fit, with that requirement in mind. (I'd try changing it, but I've been without my glasses for a week, and doing things on the computer has been very, very error-prone--even trying to write coherently. )--[[User:Short Circuit|Michael Mol]] 15:15, 28 September 2011 (UTC)
 
: I don't understand (above) the statement saying why the "extra data" (the port) is required to be ignored (or is being mishandled). I see no problem with parsing/displaying it. If it can be parsed, it's shouldn't be an error to include it in the IP address. -- [[User:Gerard Schildberger|Gerard Schildberger]] 15:00, 23 April 2012 (UTC)
 
:: Retrospect from a few years later: my sentence "First, it requires that extra data (the port) be ignored." was unclear and ambiguous. This task was, I imagine, aimed at being a crude model of a web browser (except without any dns names or user names, etc.). It makes an odd sort of sense from that perspective. But see the next section for where this conversation drifted, back then. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 17:17, 11 May 2014 (UTC)
 
=== Port 0 ===
Line 40 ⟶ 48:
::: More to the point, we're not talking about TCP or UDP, but IP. --[[User:Short Circuit|Michael Mol]] 13:56, 29 September 2011 (UTC)
:::: We are indeed talking about IP addresses, but the task also asks us to deal with ports, and IP does not have ports without something like TCP or UDP. --[[User:Rdm|Rdm]] 14:10, 29 September 2011 (UTC)
::::: Fair enough. (And I wouldn't want to remove the port-awareness requirement, because of its impact on parsing.) --[[User:Short Circuit|Michael Mol]] 14:12, 29 September 2011 (UTC)
 
==format description of IP addresses==
 
I think it would be a good idea to provide a link (or links) describing the various (legal) formats of an IP address. -- [[User:Gerard Schildberger|Gerard Schildberger]] 14:06, 23 April 2012 (UTC)
 
==other IP address formats==
 
I noticed that at least two (or more) other formats for IP address aren't represented in the examples (used for input):
 
* "slash" or CIDR or netmask format: <tt> w.x.y.z/25 </tt> for instance.
* IPv4-compatible address: <tt> 0:0:0:0:0:0:w.x.y.z </tt> or <tt> ::w.x.y.z </tt>
* IPv4-mapped address: <tt> 0:0:0:0:0:FFFF:w.x.t.z </tt> or <tt> ::FFFF:w,x,y,z </tt>
* 6to4 address: <tt> 2002::/16 </tt> described in RFC 3056.
* ISATAP address (Intra-Site Automatic Tunnel Addressing Protocol): <tt> :::5EFE:w.x.y.z </tt> and also <tt> FE80::/64 </tt> described in RFC 4214.
* Teredo address: <tt> 2001::/32 </tt> described in RFC 4380.
[All of this is way over my comprehension level.]
<br>I see nothing detailed above that would exclude these from adding them as examples (for input).
-- [[User:Gerard Schildberger|Gerard Schildberger]] 14:06, 23 April 2012 (UTC)
 
: I'd ignore anything with a <code>/</code> in it; they specify ''networks'', not individual addresses. Similarly, I also wouldn't worry about the v4-in-v6 magic. It's enough to handle normal IPv4 (in conventional dotted quad form) and IPv6 (with usual abbreviating, as described by the RFC on that). –[[User:Dkf|Donal Fellows]] ([[User talk:Dkf|talk]]) 16:38, 11 May 2014 (UTC)