< draft-carpenter-6man-rfc6874bis-02.txt		draft-carpenter-6man-rfc6874bis-03.txt >
	6MAN B. Carpenter		6MAN B. Carpenter
	Internet-Draft Univ. of Auckland		Internet-Draft Univ. of Auckland
	Obsoletes: 6874 (if approved) S. Cheshire		Obsoletes: 6874 (if approved) S. Cheshire
	Updates: 3986 (if approved) Apple Inc.		Updates: 3986, 3987 (if approved) Apple Inc.
	Intended status: Standards Track R. Hinden		Intended status: Standards Track R. Hinden
	Expires: 18 February 2022 Check Point Software		Expires: 12 August 2022 Check Point Software
	17 August 2021		8 February 2022
	Representing IPv6 Zone Identifiers in Address Literals and Uniform		Representing IPv6 Zone Identifiers in Address Literals and Uniform
	Resource Identifiers		Resource Identifiers
	draft-carpenter-6man-rfc6874bis-02		draft-carpenter-6man-rfc6874bis-03
	Abstract		Abstract
	This document describes how the zone identifier of an IPv6 scoped		This document describes how the zone identifier of an IPv6 scoped
	address, defined as <zone_id> in the IPv6 Scoped Address Architecture		address, defined as <zone_id> in the IPv6 Scoped Address Architecture
	(RFC 4007), can be represented in a literal IPv6 address and in a		(RFC 4007), can be represented in a literal IPv6 address and in a
	Uniform Resource Identifier that includes such a literal address. It		Uniform Resource Identifier that includes such a literal address. It
	updates the URI Generic Syntax specification (RFC 3986) accordingly,		updates the URI Generic Syntax and Internationalized Resource
	and obsoletes RFC 6874.		Identifier specifications (RFC 3986, RFC 3987) accordingly, and
			obsoletes RFC 6874.
	Discussion Venue		Discussion Venue
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Discussion of this document takes place on the 6MAN mailing list		Discussion of this document takes place on the 6MAN mailing list
	(ipv6@ietf.org), which is archived at		(ipv6@ietf.org), which is archived at
	https://mailarchive.ietf.org/arch/browse/ipv6/		https://mailarchive.ietf.org/arch/browse/ipv6/
	(https://mailarchive.ietf.org/arch/browse/ipv6/).		(https://mailarchive.ietf.org/arch/browse/ipv6/).
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 49 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 18 February 2022.		This Internet-Draft will expire on 12 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Issues with Implementing RFC 6874 . . . . . . . . . . . . . . 4		2. Issues with Implementing RFC 6874 . . . . . . . . . . . . . . 4
	3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . 6		4. URI Parsers . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Options Considered . . . . . . . . . . . . . . . . . 9		Appendix A. Options Considered . . . . . . . . . . . . . . . . . 9
	Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10		Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The Uniform Resource Identifier (URI) syntax specification [RFC3986]		The Uniform Resource Identifier (URI) syntax specification [RFC3986]
	defined how a literal IPv6 address can be represented in the "host"		defined how a literal IPv6 address can be represented in the "host"
	part of a URI. Two months later, the IPv6 Scoped Address		part of a URI. Two months later, the IPv6 Scoped Address
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	The IPv6 Scoped Address Architecture specification [RFC4007] does not		The IPv6 Scoped Address Architecture specification [RFC4007] does not
	specify how zone identifiers are to be represented in URIs.		specify how zone identifiers are to be represented in URIs.
	Practical experience has shown that this feature is useful or		Practical experience has shown that this feature is useful or
	necessary, in at least three use cases:		necessary, in at least three use cases:
	1. When using a web browser for simple debugging actions involving		1. When using a web browser for simple debugging actions involving
	link-local addresses on a host with more than one active link		link-local addresses on a host with more than one active link
	interface.		interface.
	2. When using a web browser to reconfigure a misconfigured device		2. When using a web browser to configure or reconfigure a device
	which only has a link local address and whose only configuration		which only has a link local address and whose only configuration
	tool is a web server, again from a host with more than one active		tool is a web server, again from a host with more than one active
	link interface.		link interface.
	3. When using an HTTP-based protocol for establishing link- local		3. When using an HTTP-based protocol for establishing link-local
	relationships, such as the Apple CUPS printing mechanism [CUPS].		relationships, such as the Apple CUPS printing mechanism [CUPS].
	It should be noted that whereas some operating systems and network		It should be noted that whereas some operating systems and network
	APIs support a default zone identifier as described in [RFC4007],		APIs support a default zone identifier as described in [RFC4007],
	others do not, and for them an appropriate URI syntax is particularly		others do not, and for them an appropriate URI syntax is particularly
	important.		important.
	In the past, some browser versions directly accepted the IPv6 Scoped		In the past, some browser versions directly accepted the IPv6 Scoped
	Address syntax [RFC4007] for scoped IPv6 addresses embedded in URIs,		Address syntax [RFC4007] for scoped IPv6 addresses embedded in URIs,
	i.e., they were coded to interpret a "%" sign following the literal		i.e., they were coded to interpret a "%" sign following the literal
	address as introducing a zone identifier [RFC4007], instead of		address as introducing a zone identifier [RFC4007], instead of
	introducing two hexadecimal characters representing some percent-		introducing two hexadecimal characters representing some percent-
	encoded octet [RFC3986]. Clearly, interpreting the "%" sign as		encoded octet [RFC3986]. Clearly, interpreting the "%" sign as
	introducing a zone identifier is very convenient for users, although		introducing a zone identifier is very convenient for users, although
	it formally breaches the established URI syntax [RFC3986]. This		it is not supported by the URI syntax [RFC3986] or the
	document defines an alternative approach that respects and extends		Internationalized Resource Identifier (IRI) syntax [RFC3987].
	the rules of URI syntax, and IPv6 literals in general, to be		Therefore, this document updates RFC 3986 and RFC 3987 by adding
	consistent.		syntax to allow a zone identifier to be included in a literal IPv6
			address within a URI.
	Thus, this document updates the URI syntax specification [RFC3986] by
	adding syntax to allow a zone identifier to be included in a literal
	IPv6 address within a URI.
	It should be noted that in contexts other than a user interface, a		It should be noted that in contexts other than a user interface, a
	zone identifier is mapped into a numeric zone index or interface		zone identifier is mapped into a numeric zone index or interface
	number. The MIB textual convention InetZoneIndex [RFC4001] and the		number. The MIB textual convention InetZoneIndex [RFC4001] and the
	socket interface [RFC3493] define this as a 32-bit unsigned integer.		socket interface [RFC3493] define this as a 32-bit unsigned integer.
	The mapping between the human-readable zone identifier string and the		The mapping between the human-readable zone identifier string and the
	numeric value is a host-specific function that varies between		numeric value is a host-specific function that varies between
	operating systems. The present document is concerned only with the		operating systems. The present document is concerned only with the
	human-readable string.		human-readable string.
	Several alternative solutions were considered while this document was		Several alternative solutions were considered while this document was
	developed. Appendix A briefly describes the various options and		developed. Appendix A briefly describes the various options and
	their advantages and disadvantages.		their advantages and disadvantages.
	This document obsoletes its predecessor [RFC6874] by greatly		This document obsoletes its predecessor [RFC6874] by greatly
	simplifying its recommendations and requirements for web browsers.		simplifying its recommendations and requirements for URI parsers.
	Its effect on the formal URI syntax [RFC3986] is exactly the same as		Its effect on the formal URI syntax [RFC3986] is different from that
	that of RFC 6874.		of RFC 6874.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Issues with Implementing RFC 6874		2. Issues with Implementing RFC 6874
	Several issues prevented RFC 6874 being implemented in browsers:		Several issues prevented RFC 6874 being implemented in browsers:
	1. There was some disagreement with requiring percent-encoding of		1. There was some disagreement with requiring percent-encoding of
	the "%" sign preceding a zone identifier. This requirement is		the "%" sign preceding a zone identifier. This requirement is
	retained in the present document.		dropped in the present document.
	2. The requirement to delete any zone identifier before emitting a		2. The requirement to delete any zone identifier before emitting a
	URI from the host in an HTTP message was considered both too		URI from the host in an HTTP message was considered both too
	complex to implement and in violation of normal HTTP practice		complex to implement and in violation of normal HTTP practice
	[RFC7230]. This requirement has been dropped from the present		[RFC7230]. This requirement has been dropped from the present
	document.		document.
	3. The suggestion to pragmatically allow a bare "%" sign when this		3. The suggestion to pragmatically allow a bare "%" sign when this
	would be unambiguous was considered both too complex to implement		would be unambiguous was considered both too complex to implement
	and confusing for users. This suggestion has been dropped from		and confusing for users. This suggestion has been dropped from
	the present document.		the present document since it is now irrelevant.
	3. Specification		3. Specification
	According to IPv6 Scoped Address syntax [RFC4007], a zone identifier		According to IPv6 Scoped Address syntax [RFC4007], a zone identifier
	is attached to the textual representation of an IPv6 address by		is attached to the textual representation of an IPv6 address by
	concatenating "%" followed by <zone_id>, where <zone_id> is a string		concatenating "%" followed by <zone_id>, where <zone_id> is a string
	identifying the zone of the address. However, the IPv6 Scoped		identifying the zone of the address. However, the IPv6 Scoped
	Address Architecture specification gives no precise definition of the		Address Architecture specification gives no precise definition of the
	character set allowed in <zone_id>. There are no rules or de facto		character set allowed in <zone_id>. There are no rules or de facto
	standards for this. For example, the first Ethernet interface in a		standards for this. For example, the first Ethernet interface in a
	host might be called %0, %1, %en1, %eth0, or whatever the implementer		host might be called %0, %1, %en1, %eth0, or whatever the implementer
	happened to choose. Also, %25 would be valid.		happened to choose. Also, %25 would be valid.
	In a URI, a literal IPv6 address is always embedded between "[" and		In a URI, a literal IPv6 address is always embedded between "[" and
	"]". This document specifies how a <zone_id> can be appended to the		"]". This document specifies how a <zone_id> can be appended to the
	address. According to Section 2.4 of [RFC3986], "%" must be percent-		address. According to the text in Section 2.4 of [RFC3986], "%" must
	encoded to be used as data within a URI, so any occurrences of		be percent-encoded as "%25" to be used as data within a URI.
	literal "%" symbols in a URI MUST be percent-encoded and represented		However, in the formal ABNF syntax of RFC 3986, this only applies
	in the form "%25". Thus, the scoped address fe80::abcd%en1 would		where the "pct-encoded" element appears. For this reason, it is
	appear in a URI as http://[fe80::abcd%25en1].		possible to extend the ABNF such that the scoped address
			fe80::abcd%en1 would appear in a URI as http://[fe80::abcd%en1] or
	* Open Issue 1: This choice needs to be re-discussed as there is an		https://[fe80::abcd%en1].
	argument that URI parsers could be coded to avoid percent-encoding
	here if so directed by the ABNF syntax. This depends on the exact
	interpretation of Section 2.4 of [RFC3986]
	* Open Issue 2: Depending on the outcome of the previous issue,
	there is an argument that an alternative separator (specifically
	"-") would be preferable to "%25".
	A <zone_id> SHOULD contain only ASCII characters classified as		A <zone_id> MUST contain only ASCII characters classified as
	"unreserved" for use in URIs [RFC3986]. This excludes characters		"unreserved" for use in URIs [RFC3986]. This excludes characters
	such as "]" or even "%" that would complicate parsing. However, the		such as "]" or even "%" that would complicate parsing. The <zone_id>
	syntax described below does allow such characters to be percent-		"25" cannot be forbidden since it is valid in some operating systems,
	encoded, for compatibility with existing devices that use them.		so a parser MUST NOT apply percent decoding to a URI such as
			http://[fe80::abcd%25].
	If an operating system uses any other characters in zone or interface		If an operating system uses any other characters in zone or interface
	identifiers that are not in the "unreserved" character set, they MUST		identifiers that are not in the "unreserved" character set, they
	be represented using percent encoding [RFC3986].		cannot be used in a URI.
	We now present the necessary formal syntax.		We now present the corresponding formal syntax.
	The URI syntax specification [RFC3986] formally defined the IPv6		The URI syntax specification [RFC3986] formally defines the IPv6
	literal format in ABNF [RFC5234] by the following rule:		literal format in ABNF [RFC5234] by the following rule:
	IP-literal = "[" ( IPv6address / IPvFuture ) "]"		IP-literal = "[" ( IPv6address / IPvFuture ) "]"
	To provide support for a zone identifier, the existing syntax of		To provide support for a zone identifier, the existing syntax of
	IPv6address is retained, and a zone identifier may be added		IPv6address is retained, and a zone identifier may be added
	optionally to any literal address. This syntax allows flexibility		optionally to any literal address. This syntax allows flexibility
	for unknown future uses. The rule quoted above from the previous URI		for unknown future uses. The rule quoted above from [RFC3986] is
	syntax specification [RFC3986] is replaced by three rules:		replaced by three rules:
	IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]"
	ZoneID = 1*( unreserved / pct-encoded )
	IPv6addrz = IPv6address "%25" ZoneID
	Alternative rules for Issue 1 above:
	IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]"		IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]"
	ZoneID = 1*( unreserved )		ZoneID = 1*( unreserved )
	IPv6addrz = IPv6address "%" ZoneID		IPv6addrz = IPv6address "%" ZoneID
	Alternative rules for Issue 2 above:		This change also applies to [RFC3987].
	IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]"
	ZoneID = 1*( unreserved )
	IPv6addrz = IPv6address "-" ZoneID
	This syntax fills the gap that is described at the end of		This syntax fills the gap that is described at the end of
	Section 11.7 of the IPv6 Scoped Address Architecture specification		Section 11.7 of the IPv6 Scoped Address Architecture specification
	[RFC4007].		[RFC4007]. It replaces and obsoletes the syntax in Section 2 of
			[RFC6874].
	The established rules for textual representation of IPv6 addresses		The established rules for textual representation of IPv6 addresses
	[RFC5952] SHOULD be applied in producing URIs.		[RFC5952] SHOULD be applied in producing URIs.
	The URI syntax specification [RFC3986] states that URIs have a global		The URI syntax specification [RFC3986] states that URIs have a global
	scope, but that in some cases their interpretation depends on the		scope, but that in some cases their interpretation depends on the
	end-user's context. URIs including a ZoneID are to be interpreted		end-user's context. URIs including a ZoneID are to be interpreted
	only in the context of the host at which they originate, since the		only in the context of the host at which they originate, since the
	ZoneID is of local significance only.		ZoneID is of local significance only.
	The IPv6 Scoped Address Architecture specification [RFC4007] offers		The IPv6 Scoped Address Architecture specification [RFC4007] offers
	guidance on how the ZoneID affects interface/address selection inside		guidance on how the ZoneID affects interface/address selection inside
	the IPv6 stack. Note that the behaviour of an IPv6 stack, if it is		the IPv6 stack. Note that the behaviour of an IPv6 stack, if it is
	passed a non-null zone index for an address other than link-local, is		passed a non-null zone index for an address other than link-local, is
	undefined.		undefined.
	4. Web Browsers		4. URI Parsers
	This section discusses how web browsers might handle this syntax		This section discusses how URI parsers, such as those embedded in web
	extension. Unfortunately, there is no formal distinction between the		browsers, might handle this syntax extension. Unfortunately, there
	syntax allowed in a browser's input dialogue box and the syntax		is no formal distinction between the syntax allowed in a browser's
	allowed in URIs. For this reason, no normative statements are made		input dialogue box and the syntax allowed in URIs. For this reason,
	in this section.		no normative statements are made in this section.
	Due to the lack of defined syntax, web browsers have been		In practice, although parsers respect the established syntax, they
	inconsistent in providing for ZoneIDs. Most have no support, but		are coded pragmatically rather than being formally syntax-driven.
	there have been examples of ad hoc support. For example, some		Typically, IP address literals are handled by an explicit code path.
	versions of Firefox allowed the use of a ZoneID preceded by a bare		Parsers have been inconsistent in providing for ZoneIDs. Most have
	"%" character, but this feature was removed for consistency with		no support, but there have been examples of ad hoc support. For
	established syntax [RFC3986]. As another example, some versions of		example, some versions of Firefox allowed the use of a ZoneID
	Internet Explorer allowed use of a ZoneID preceded by a "%" character		preceded by a bare "%" character, but this feature was removed for
	encoded as "%25", still beyond the syntax allowed by the established		consistency with established syntax [RFC3986]. As another example,
	rules [RFC3986]. This syntax extension is in fact used internally in		some versions of Internet Explorer allowed use of a ZoneID preceded
	the Windows operating system and some of its APIs.		by a "%" character encoded as "%25", still beyond the syntax allowed
			by the established rules [RFC3986]. This syntax extension is in fact
			used internally in the Windows operating system and some of its APIs.
	It is desirable for all browsers to recognise a ZoneID according to		It is desirable for all URI parsers to recognise a ZoneID according
	the above syntax.		to the syntax defined in Section 3.
	URIs including a ZoneID have no meaning outside the originating HTTP		URIs including a ZoneID have no meaning outside the originating HTTP
	client node. However, in some use cases, such as CUPS mentioned		client node. However, in some use cases, such as CUPS mentioned
	above, the URI will be reflected back to the client.		above, the URI will be reflected back to the client.
	The normal diagnostic usage for the ZoneID syntax will cause it to be		The various use cases for the ZoneID syntax will cause it to be
	entered in the browser's input dialogue box. Thus, URIs including a		entered in a browser's input dialogue box. Thus, URIs including a
	ZoneID are unlikely to be encountered in HTML documents. However, if		ZoneID are unlikely to occur in HTML documents. However, if they do
	they do (for example, in a diagnostic script coded in HTML), it would		(for example, in a diagnostic script coded in HTML), it would be
	be appropriate to treat them exactly as above.		appropriate to treat them exactly as above.
	5. Security Considerations		5. Security Considerations
	The security considerations from the URI syntax specification		The security considerations from the URI syntax specification
	[RFC3986] and the IPv6 Scoped Address Architecture specification		[RFC3986] and the IPv6 Scoped Address Architecture specification
	[RFC4007] apply. In particular, this URI format creates a specific		[RFC4007] apply. In particular, this URI format creates a specific
	pathway by which a deceitful zone index might be communicated, as		pathway by which a deceitful zone index might be communicated, as
	mentioned in the final security consideration of the Scoped Address		mentioned in the final security consideration of the Scoped Address
	Architecture specification.		Architecture specification.
	To limit this risk, implementations MUST NOT allow use of this format		To limit this risk, implementations MUST NOT allow use of this format
	except for well-defined usages, such as sending to link-local		except for well-defined usages, such as sending to link-local
	addresses under prefix fe80::/10. At the time of writing, this is		addresses under prefix fe80::/10. At the time of writing, this is
	the only well-defined usage known.		the only well-defined usage known.
	6. Acknowledgements		6. Acknowledgements
	The lack of this format was first pointed out by Margaret Wasserman		The lack of this format was first pointed out by Margaret Wasserman
	and later by Kerry Lynn. A previous draft document by Martin Duerst		and later by Kerry Lynn. A previous draft document by Bill Fenner
	and Bill Fenner [LITERAL-ZONE] discussed this topic but was not		and Martin Dürst [LITERAL-ZONE] discussed this topic but was not
	finalised. Michael Sweet and Andrew Cady explained some of the		finalised. Michael Sweet and Andrew Cady explained some of the
	difficulties caused by RFC 6874.		difficulties caused by RFC 6874. The ABNF syntax proposed above was
			drafted by Andrew Cady.
	Valuable comments and contributions were made by Karl Auer, Carsten		Valuable comments and contributions were made by Karl Auer, Carsten
	Bormann, Benoit Claise, Stephen Farrell, Brian Haberman, Ted Hardie,		Bormann, Benoit Claise, Martin Dürst, Stephen Farrell, Brian
	Philip Homburg, Tatuya Jinmei, Yves Lafon, Barry Leiba, Radia		Haberman, Ted Hardie, Philip Homburg, Tatuya Jinmei, Yves Lafon,
	Perlman, Tom Petch, Michael Richardson, Tomoyuki Sahara, Juergen		Barry Leiba, Radia Perlman, Tom Petch, Michael Richardson, Tomoyuki
	Schoenwaelder, Nico Schottelius, Dave Thaler, Martin Thomson, Ole		Sahara, Juergen Schoenwaelder, Nico Schottelius, Dave Thaler, Martin
	Troan, and others.		Thomson, Ole Troan, and others.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
			[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
			Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
			January 2005, <https://www.rfc-editor.org/info/rfc3987>.
	[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and		[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
	B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,		B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
	DOI 10.17487/RFC4007, March 2005,		DOI 10.17487/RFC4007, March 2005,
	<https://www.rfc-editor.org/info/rfc4007>.		<https://www.rfc-editor.org/info/rfc4007>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	skipping to change at page 8, line 41 ¶		skipping to change at page 8, line 30 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
	[CUPS] Apple, "CUPS open source printing system", 2021,		[CUPS] Apple, "CUPS open source printing system", 2021,
	<https://www.cups.org/>.		<https://www.cups.org/>.
	[LITERAL-ZONE]		[LITERAL-ZONE]
	Fenner, B. and M. Duerst, "Formats for IPv6 Scope Zone		Fenner, B. and M. Dürst, "Formats for IPv6 Scope Zone
	Identifiers in Literal Address Formats", Work in Progress,		Identifiers in Literal Address Formats", Work in Progress,
	October 2005.		October 2005.
	[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.		[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
	Stevens, "Basic Socket Interface Extensions for IPv6",		Stevens, "Basic Socket Interface Extensions for IPv6",
	RFC 3493, DOI 10.17487/RFC3493, February 2003,		RFC 3493, DOI 10.17487/RFC3493, February 2003,
	<https://www.rfc-editor.org/info/rfc3493>.		<https://www.rfc-editor.org/info/rfc3493>.
	[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.		[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
	Schoenwaelder, "Textual Conventions for Internet Network		Schoenwaelder, "Textual Conventions for Internet Network
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 7 ¶
	Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,		Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
	February 2013, <https://www.rfc-editor.org/info/rfc6874>.		February 2013, <https://www.rfc-editor.org/info/rfc6874>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	Appendix A. Options Considered		Appendix A. Options Considered
	This section will be updated as necessary after the open issues are
	resolved.
	The syntax defined above allows a ZoneID to be added to any IPv6		The syntax defined above allows a ZoneID to be added to any IPv6
	address. The 6man WG discussed and rejected an alternative in which		address. The 6man WG discussed and rejected an alternative in which
	the existing syntax of IPv6address would be extended by an option to		the existing syntax of IPv6address would be extended by an option to
	add the ZoneID only for the case of link-local addresses. It was		add the ZoneID only for the case of link-local addresses. It was
	felt that the solution presented in this document offers more		felt that the solution presented in this document offers more
	flexibility for future uses and is more straightforward to implement.		flexibility for future uses and is more straightforward to implement.
	The various syntax options considered are now briefly described.		The various syntax options considered are now briefly described.
	1. Leave the problem unsolved.		1. Leave the problem unsolved.
	skipping to change at page 10, line 5 ¶		skipping to change at page 9, line 34 ¶
	Disadvantage: less convenient than using a browser. Leaves some		Disadvantage: less convenient than using a browser. Leaves some
	use cases unsatisfied.		use cases unsatisfied.
	2. Simply use the percent character:		2. Simply use the percent character:
	http://[fe80::abcd%en1]		http://[fe80::abcd%en1]
	Advantage: allows use of browser; allows cut and paste.		Advantage: allows use of browser; allows cut and paste.
	Disadvantage: invalid syntax under RFC 3986; not acceptable to		Disadvantage: requires code changes to all URI parsers.
	URI community.
			This is the option chosen for standardisation.
	3. Simply use an alternative separator:		3. Simply use an alternative separator:
	http://[fe80::abcd-en1]		http://[fe80::abcd-en1]
	Advantage: allows use of browser; simple syntax.		Advantage: allows use of browser; simple syntax.
	Disadvantage: Requires all IPv6 address literal parsers and		Disadvantage: Requires all IPv6 address literal parsers and
	generators to be updated in order to allow simple cut and paste;		generators to be updated in order to allow simple cut and paste;
	inconsistent with existing tools and practice.		inconsistent with existing tools and practice.
	skipping to change at page 10, line 45 ¶		skipping to change at page 10, line 27 ¶
	already-established URI syntax rules [RFC 3986]:		already-established URI syntax rules [RFC 3986]:
	http://[fe80::abcd%25en1]		http://[fe80::abcd%25en1]
	Advantage: allows use of browser; consistent with general URI		Advantage: allows use of browser; consistent with general URI
	syntax.		syntax.
	Disadvantage: somewhat ugly and confusing; doesn't allow simple		Disadvantage: somewhat ugly and confusing; doesn't allow simple
	cut and paste.		cut and paste.
	This is the option chosen for standardisation.
	Appendix B. Change log		Appendix B. Change log
	This section is to be removed before publishing as an RFC.		This section is to be removed before publishing as an RFC.
	* draft-carpenter-6man-rfc6874bis-02, 2021-08-12:		* draft-carpenter-6man-rfc6874bis-03, 2022-02-08:
			- Changed to bare % signs.
			- Added IRIs, RFC3987
			- Editorial fixes
			* draft-carpenter-6man-rfc6874bis-02, 2021-18-12:
	- Give details of open issues		- Give details of open issues
	- Update authorship		- Update authorship
	- Editorial fixes		- Editorial fixes
	* draft-carpenter-6man-rfc6874bis-01, 2021-07-11:		* draft-carpenter-6man-rfc6874bis-01, 2021-07-11:
	- Added section on issues with RFC6874		- Added section on issues with RFC6874
End of changes. 39 change blocks.
	108 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/