Michael, I don't know where the decision to use this syntax in CUPS (IPv6addrz = IPv6address "%25" ZoneID / "v1." IPv6address "+" ZoneID) was debated - I don't think it was here, and I don't generally follow the URI discussions. My opinion, fwiw, is that the "IPvFuture" branch invented by the URI people (again without any discussion here, iirc) is exactly the sort of vague extensibility that we should avoid (RFC 6709).
The other thing you should realise is that the URI people were already quite annoyed by the RFC 6874 update, which took a lot of persuasion. Going back to them with another formal syntax change would be a very hard slog. That said, documenting something that is actually used, even if it's a formal syntax violation, is always a good thing. I think your path of least resistance is a short informational RFC describing the practice adopted in CUPS. However, I don't think we should change the formal statement that a ZoneID must not be sent out on the wire; again, documenting the practice may be advisable, but encouraging it certainly isn't, for the reasons given in the Security Considerations of RFC 6874. Regards Brian On 28/08/2013 03:59, Michael Sweet wrote: > All, > > This is my promised ID that updates RFC 6874 to add the IPvFuture syntax that > was adopted from the previous, abandoned draft on this subject (back in 2005) > and is implemented widely in clients and printers, and also updates the HTTP > conformance requirements and guidance to include the client's zone ID in > requests sent to the server (so that the server can generate link-local URIs > the client can actually use...) > > Comments welcome... > > > Begin forwarded message: > >> From: internet-dra...@ietf.org >> Subject: New Version Notification for draft-sweet-uri-zoneid-00.txt >> Date: 27 August, 2013 11:55:38 AM EDT >> To: Stuart Cheshire <chesh...@apple.com>, Michael Sweet <msw...@apple.com>, >> "Robert M. Hinden" <bob.hin...@gmail.com>, Brian Carpenter >> <brian.e.carpen...@gmail.com> >> >> >> A new version of I-D, draft-sweet-uri-zoneid-00.txt >> has been successfully submitted by Michael Sweet and posted to the >> IETF repository. >> >> Filename: draft-sweet-uri-zoneid >> Revision: 00 >> Title: Representing IPv6 Zone Identifiers in Address Literals >> and Uniform Resource Identifiers >> Creation date: 2013-08-27 >> Group: Individual Submission >> Number of pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-sweet-uri-zoneid-00.txt >> Status: http://datatracker.ietf.org/doc/draft-sweet-uri-zoneid >> Htmlized: http://tools.ietf.org/html/draft-sweet-uri-zoneid-00 >> >> >> Abstract: >> This document describes how the zone identifier of an IPv6 scoped >> address, defined as <zone_id> in the IPv6 Scoped Address Architecture >> (RFC 4007), can be represented in a literal IPv6 address and in a >> Uniform Resource Identifier that includes such a literal address. It >> updates the URI Generic Syntax specification (RFC 3986) accordingly. >> >> [ Editor's note: This draft adds the IPvFuture format used by CUPS >> since 2005, addresses some misconceptions of how zoneid's are not >> useful to HTTP servers, and is intended to replace RFC 6874. ] >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
