Re: [cotvnc-devel] cotvnc-devel Digest, Vol 10, Issue 8

[Jared M. <jmc...@df...>]

Do we want to be that restrictive?  I don't use ipv6, but I wouldn't 
be surprised if the shortened versions won't be popular since it 
gives you less to remember.  Personally, I'd rather do this:

host
host:port
ipv6_host
[ipv6_host]
[ipv6_host]:port

where

"host" is any alpha/numeric combination with decimals (no white space, etc)
"port" is a set of digits whose value is less than 65536
"ipv6_host" is two or more colons, with optional hex values less than 
0xFFFF, and periods

That allows us to properly get the host and port in all situations 
and doesn't cut out any valid addresses. Any invalid addresses that 
get through will be caught on the connect attempt that will bring up 
the error:

The host "host" could not be found.

The user should be able to use that error to figure out the problem. 
At the end of the day, even if we have a perfect parser for validity, 
until they try to connect, we don't know if the address is correct, 
so personally I don't think we need to go overkill on the validation, 
just make sure we can pull the right pieces out. However, if you want 
to go down the validation, we can certainly try it and see how it 
goes. Until IPv6 actually becomes popular, I don't think we'll have a 
good grasp of what users will expect the programs to do, so either 
one of us could be right in the long term. Either way, we should get 
something in so we can start to code and test the actual IPv6 network 
code.

Jared

At 12:12 PM -0700 3/17/07, Jason Harris wrote:
>From the wikipedia page, it looks as though we should handle any of 
>the following:
>
>	hostName
>	hostName:port
>	a.a.a.a
>	a.a.a.a:port
>	b:b:b:b:b:b:b:b
>	[b:b:b:b:b:b:b:b]:port
>
>where
>
>	"hostName" is a valid alphanumeric host name
>	"port" is a set of digits whose value is less than 65536
>	"a" is a set of digits whose value is less than 256
>	"b" is a set of hex digits whose value is less than 0xFFFF.
>
>The page specifically says that using a port is only allowed when 
>the rectangular brackets are present.  We would not handle the 
>double-colon syntax.
>
>Jason
>
>
>On Mar 16, 2007, at 6:33 PM, Jared McIntyre wrote:
>
>>That only covers a small part of IPv6.
>>
>>http://en.wikipedia.org/wiki/IPv6#Addressing
>>
>>>How about using a custom NSFormatter that checks to see whether 
>>>the host text field is one of the following:
>>>
>>>	string with no spaces or colons
>>>	string with no spaces, one colon, followed by digits less than 65535
>>>	seven iterations of four numbers separated by periods
>>>	seven iterations of four numbers separated by periods, one 
>>>colon, followed by digits less than 65535
>>>	seven iterations of four numbers separated by periods inside 
>>>square brackets
>>>	seven iterations of four numbers separated by periods inside 
>>>square brackets, one colon, followed by digits less than 65535
>>>
>>>Here are regexes off the top of my head for the above, quite 
>>>possibly wrong (but slightly tested in BBEdit to make sure I'm not 
>>>totally insane):
>>>
>>>	[^ :]+
>>>	[^ :]+:[0-9]+
>>>	([0-9]{4}\.){6}[0-9]{4}
>>>	([0-9]{4}\.){6}[0-9]{4}:[0-9]+
>>>	\[([0-9]{4}\.){6}[0-9]{4}\]
>>>	\[([0-9]{4}\.){6}[0-9]{4}\]:[0-9]+
>>>
>>>Doing this in an NSFormatter puts the logic where it belongs, in 
>>>text entry.  I can write this NSFormatter if someone else verifies 
>>>that it seems like a reasonable thing to do.
>>>
>>>Jason
>>>
>>>On Mar 16, 2007, at 5:54 PM, Jared McIntyre wrote:
>>>
>>>>I think it is better to let the system handle most of the 
>>>>validation of the host address.  There is just an insane number 
>>>>of ways to write an IPv6 address and I'd much rather let the OS 
>>>>devs handle that mess. It looks like the proper way to do a 
>>>>hostport with ipv6 is the format [address]:port where the 
>>>>brackets are required. Or at least that is the proper way to do 
>>>>it in a URL, and without the brackets it would be next to 
>>>>impossible unless you require them to write out the full 
>>>>xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx which is only one valid 
>>>>way to write the address. So, that should be pretty easy to add a 
>>>>check in our current algorithm. Just check if the first character 
>>>>is a [, and if it is, there should be a ]: combination after 
>>>>which is the port. Otherwise process it as we are doing now. We 
>>>>could put some checks in to make sure the port is a valid number 
>>>>and in the range of ports and there is only one colon after that.
>>>>
>>>>Could we do more checking than that, sure we could, but I don't 
>>>>think it is worth it, I think we would likely get it wrong in the 
>>>>stranger areas of the naming conventions of domain names, ipv4, 
>>>>and ipv6 addresses (not to mention the upcoming unicode domain 
>>>>names). Now that I've put a fix in so that when a connect() fails 
>>>>because the address is invalid we display a meaningful message 
>>>>including what we think the host was, this should help people fix 
>>>>their problems more easily.
>>>>
>>>>Jared
>>>>
>>>>>  >> From: Jared McIntyre <jmc...@df...>
>>>>>>  ...
>>>>>>>  I was looking at the IPv6 request. To do this, I need to gut the
>>>>>>>  HostAndPort code from the system.  This isn't particularly difficult,
>>>>>>>  we already access port and host by themselves in most places, but the
>>>>>>>  command line is using HostAndPort. We will need to change the command
>>>>>>>  line interface and UI to not support the host:port format. I propose
>>>>>>>  the addition of the -p and --port parameters to replace the existing
>>>>>>>  functionality.
>>>>>>
>>>>>>  I really don't like this; the host:port syntax is well-known and a
>>>>>>  de-facto standard. Browsers supports it, so why cannot we?
>>>>>>
>>>>>>  Another reason to support host:port (and the IPv6-style
>>>>>>  [1:2:3::4]:port syntax) is compatibility with other VNC
>>>>>>  implementations.
>>>>>>
>>>>>>  So please, don't remove the host:port support.
>>>>>
>>>>>
>>>>>Whoops, I was reading too fast when I gave the go-ahead on this 
>>>>>one.  Please don't remove host:port - we had about a bajillion 
>>>>>requests for it before we supported it.
>>>>>
>>>>>If someone tells me all of the possible syntaxes needed to 
>>>>>support IPv4 host, IPv4 host + port, IPv6 host, and IPv6 host + 
>>>>>port, I'll write a regex parser that pulls out the relevant info.
>>>>>
>>>>>Jason
>>>>>
>>>>>
>>>>>-------------------------------------------------------------------------
>>>>>Take Surveys. Earn Cash. Influence the Future of IT
>>>>>Join SourceForge.net's Techsay panel and you'll get the chance 
>>>>>to share your
>>>>>opinions on IT & business topics through brief surveys-and earn cash
>>>>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>>>_______________________________________________
>>>>>cotvnc-devel mailing list
>>>>>cot...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/cotvnc-devel