Re: URL parsing and IPv6 addresses

Earlier, <Larry Masinter> inscribed:
> 
>    1) dotted decimal with 8 parts instead of 4
>    2) string of hex with no punctuation

I would think compliance with the IPv6 RFC on IPv6 address representation
would not be a bad thing.  My inclination is still to use a second "::"
to separate the port, if only because it avoids adding any more special
characters.  By counting ':'s in a URL, it should be possible to identify
the addressing type.
  0 colon  = IPv4 address or a hostname, no port specified.
  1 colon  = IPv4 address or a hostname, port specified.
  2-3 colons = Abbreviated IPv6 address, no port specified
  4-10 colons = Parse to find '::' pattern.  
    0 '::'s - Unabbreviated IPv6 address, no port specified
    1 '::'s - If colon count = 9, unabbreviated IPv6 address, port specified
              Otherwise, abbreviated IPv6 address, no port specified
    2 '::'s - Abbreviated IPv6 address, port specifed.  Everything up to the
              second :: is an IPv6 address.

Yes, it's ugly, but if you're going to put an IPv6 address in a URL for
what ever reason, it's going to be ugly.  If a colon isn't going to be
used to separate the port, the matching syntax should apply to IPv4 as well.
                
I do not want to use the same syntax as an email address handling, with
the '[' and ']'.  There are enough people trying to email to URL's or 
trying to browse email addresses with netscape as it is.  Also, for those
of us who start netscape from the command line:
   netscape http://[131.247.108.14]/
would have to be:
   netscape "http://[131.247.108.14]/"
because the '[' and ']' are used by the shell.  (It may just be me, but I
don't like the idea of common shell characters being used in URL's.  A
friend of mine suggested using ';' to separate the port, which would make
me rather uncomfortable. :) )

Kim

(Also, if a separator such as [] was to be used, wouldn't it make more
sense to put it around the port specifier, not the address?)

Received on Tuesday, 6 August 1996 19:40:30 UTC