Michael,
Let me repeat myself... This is not how the errata report system
is to be used. It is *not* a notification system for future proposals.
That type of notification can be accomplished by posting to the
appropriate IETF mailing list (ipv6@ietf.org in this case).
Regards,
Brian
On 5/23/13 10:42 AM, RFC Errata System wrote:
The following errata report has been submitted for RFC6874,
"Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource
Identifiers".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6874&eid=3632
--------------------------------------
Type: Technical
Reported by: Michael Sweet <msw...@apple.com>
Section: 3
Original Text
-------------
Such bare "%" signs are for user interface convenience, and need to
be turned into properly encoded characters (where "%25" encodes "%")
before the URI is used in any protocol or HTML document. However,
URIs including a ZoneID have no meaning outside the originating node.
It would therefore be highly desirable for a browser to remove the
ZoneID from a URI before including that URI in an HTTP request.
Corrected Text
--------------
Such bare "%" signs are for user interface convenience, and need to
be turned into properly encoded characters (where "%25" encodes "%")
before the URI is used in any protocol or HTML document. HTTP Clients
MUST include a ZoneID in any URIs provided in an HTTP request since
HTTP Servers will need it when generating URIs, otherwise the IPv6
address will not be usable by the Client.
Notes
-----
NOTE: PLEASE DO NOT REJECT THIS ERRATA BEFORE FURTHER REVIEW. I WILL BE
SUBMITTING A NEW DRAFT PROPOSING THESE CHANGES; THIS ERRATA CAN SERVE AS PUBLIC
NOTICE OF POTENTIAL CHANGES TO THE RFC.
The client uses the zoneid to choose a network interface to route packets to
that link local address. If the server returns a uri in its response that uses
the same link local address but without the client's zoneid, then the client
will be unable to use said uri because it won't know which interface to use.
Yes the server doesn't care about the zoneid but the client depends on it (for
link local anyways).
The client can supply the zoneid in the Host header. For example, the following
illustrates a typical IPP request using the previously recommended IPvFuture
format (which CUPS implements and uses):
POST /ipp/print HTTP/1.1
Host: [v1.fe80::1234+en0]:631
Content-Type: application/ipp
Transfer-Coding: chunked
... IPP request ...
The printer then validates the Host header and responds with URIs containing
the same Host value in any reported IPv6 link-local URIs.
The key issue is one of context - the client *may* be able to query the
interface used for a particular socket connection but it probably can't
(easily) cache and map this information in the URIs that are embedded in the
content returned by the printer, particularly when the client may have to
process said content from a variety of sources - IPP is also supported over a
USB transport, HTML can be read from disk, etc. Clients are usually unable to
connect to a given IPv6 link local address without the zoneid information to
tell them which network interface to use. And typically the only reason
clients use an IPv6 link local address is because it was handed to them by a
discovery protocol like WS-Discovery...
Requiring the client to rewrite all URIs is a tremendous burden and is
error-prone. Requiring the server to use the Host header is cheap in
comparison. Having the server validate and use the Host value also helps
interoperability since existing clients may not support the new IPv6addrz
format - for example, CUPS doesn't support it since it validates URIs and Host
values using the ABNF in RFC 3986/STD 66.
The Host header mechanism has been standard practice outside the IETF for
several years now. It is part of IPP Everywhere (Printer Working Group), Wi-Fi
Direct Print Services (Wi-Fi Alliance), IPP USB (USB Implementers Forum), and
AirPrint (Apple). It solves the problem of client-side routing of IPv6 link
local addresses that are used in URIs embedded in content returned by printers
and other embedded devices.
Hundreds of millions of printers, computers, and mobile devices have been
certified and shipped with IPv6 link local support using the IPvFuture format
over the last 8 years. The new format is incompatible with parsers that use the
ABNF in STD 66 (aka RFC 3986) and prevents the use of the Host header in HTTP
requests to provide a backwards-compatible IPv6 implementation.
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC6874 (draft-ietf-6man-uri-zoneid-06)
--------------------------------------
Title : Representing IPv6 Zone Identifiers in Address Literals
and Uniform Resource Identifiers
Publication Date : February 2013
Author(s) : B. Carpenter, S. Cheshire, R. Hinden
Category : PROPOSED STANDARD
Source : IPv6 Maintenance
Area : Internet
Stream : IETF
Verifying Party : IESG
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
