On behalf of Apple I apologise. I will talk with Michael Sweet directly and try to resolve his concerns without any more errata reports.
Stuart Cheshire On 23 May, 2013, at 07:45, Brian Haberman <[email protected]> wrote: > 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 ([email protected] 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 <[email protected]> >> >> 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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
