As per Relevance of the word addresses, we have this rfc below:
Network Working Group R.
Request for Comments: 2732
Category: Standards Track B.
L.
AT&
December 1999
Format for Literal IPv6 Addresses in URL'
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document defines the format for literal IPv6 Addresses in URL'
for implementation in World Wide Web browsers. This format has
implemented in the IPv6 versions of several widely deployed
including Microsoft Internet Explorer, Mozilla, and Lynx. It is
intended to be used in the IPv6 version of the service
protocol
This document incudes an update to the generic syntax for
Resource Identifiers defined in RFC 2396 [URL]. It defines a
for IPv6 addresses and allows the use of "[" and "]" within a
explicitly for this reserved purpose
1.
The textual representation defined for literal IPv6 addresses
[ARCH] is not directly compatible with URL's. Both use ":" and "."
characters as delimiters. This document defines the format
literal IPv6 Addresses in URL's for implementation in World Wide
browsers. The goal is to have a format that allows easy "cut"
"paste" operations with a minimum of editing of the literal address
Hinden, et al. Standards Track [Page 1]
RFC 2732 IPv6 Literal Addresses in URL's December 1999
The format defined in this document has been implemented in the IPv
versions of several widely deployed browsers including
Internet Explorer, Mozilla, and Lynx. It is also intended to be
in the IPv6 version of the service location protocol
1.1
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, if and where they
in this document, are to be interpreted as described in [KEYWORDS].
World Wide Web browsers SHOULD implement the format of IPv6
in URL's defined in this document. Other types of applications
protocols that use URL's MAY use this format
2. Literal IPv6 Address Format in URL's
To use a literal IPv6 address in a URL, the literal address should
enclosed in "[" and "]" characters. For example the
literal IPv6 addresses
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:4171
3ffe:2a00:100:7031::1
1080::8:800:200C:417
::192.9.5.5
::FFFF:129.144.52.38
2010:836B:4179::836B:4179
would be represented as in the following example URLs
http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.
http://[1080:0:0:0:8:800:200C:417A]/index.
http://[3ffe:2a00:100:7031::1]
http://[1080::8:800:200C:417A]/
http://[::192.9.5.5]/
http://[::FFFF:129.144.52.38]:80/index.
http://[2010:836B:4179::836B:4179]
3. Changes to RFC 2396
This document updates the generic syntax for Uniform
Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv
addresses and allows the use of "[" and "]" within a URI
for this reserved purpose
Hinden, et al. Standards Track [Page 2]
RFC 2732 IPv6 Literal Addresses in URL's December 1999
The following changes to the syntax in RFC 2396 are made
(1) change the 'host' non-terminal to add an IPv6 option
host = hostname | IPv4address | IPv6
ipv6reference = "[" IPv6address "]"
where IPv6address is defined as in RFC2373 [ARCH].
(2) Replace the definition of 'IPv4address' with that of RFC 2373,
it correctly defines an IPv4address as consisting of at most
decimal digits per segment
(3) Add "[" and "]" to the set of 'reserved' characters
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | "," | "[" | "]"
and remove them from the 'unwise' set
unwise = "{" | "}" | "|" | "\" | "^" | "`"
4. Security
The use of this approach to represent literal IPv6 addresses in URL'
does not introduce any known new security concerns
5. IANA
None
Hinden, et al. Standards Track [Page 3]
RFC 2732 IPv6 Literal Addresses in URL's December 1999
6. Authors'
Robert M.
313 Fairchild
Mountain View, CA 94043
Phone: +1 650 625 2004
EMail: hinden@iprg.nokia.
Web: http://www.iprg.nokia.com/~
Brian E.
iCAIR, Suite 150
1890 Maple
Evanston IL 60201
EMail: brian@icair.
Larry
AT&T
75 Willow
Menlo Park, CA 94025
EMail: LMM@acm.
Web: http://larry.masinter.
7.
[ARCH] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.
[STD-PROC] Bradner, S., The Internet Standards Process -- Revision 3,
BCP 9, RFC 2026, October 1996.
[URL] Fielding, R., Masinter, L. and T. Berners-Lee, "
Resource Identifiers: Generic Syntax", RFC 2396,
1998.
Hinden, et al. Standards Track [Page 4]
RFC 2732 IPv6 Literal Addresses in URL's December 1999
8. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Hinden, et al. Standards Track [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
