Subject: Fwd: New Version Notification for draft-sweet-uri-zoneid-01.txt

From: Michael Sweet <[email-masked]>
Date: Fri, 22 Nov 2013 16:41:54 -0500

All,

This is my promised second (informational) draft that documents the usage of the IPvFuture encoding of ZoneID's in URIs for CUPS and IPP in general.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-sweet-uri-zoneid-01.txt
> Date: November 22, 2013 at 4:38:43 PM EST
> To: Michael Sweet <[email-masked]>
> 
> 
> A new version of I-D, draft-sweet-uri-zoneid-01.txt
> has been successfully submitted by Michael Sweet and posted to the
> IETF repository.
> 
> Filename:	 draft-sweet-uri-zoneid
> Revision:	 01
> Title:		 An IPvFuture Syntax for IPv6 Link-Local Addresses
> Creation date:	 2013-11-22
> Group:		 Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-sweet-uri-zoneid-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-sweet-uri-zoneid
> Htmlized:        http://tools.ietf.org/html/draft-sweet-uri-zoneid-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-sweet-uri-zoneid-01
> 
> 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
>   documents a long-standing usage of the IPvFuture extension point
>   provided in the Uniform Resource Identifier (URI) syntax
>   specification [RFC3986].
> 
>   [ Editor's note: This draft documents the IPvFuture format originally
>   defined in [LITERAL-ZONE] and used by CUPS since 2005.  A separate,
>   incompatible format was defined and published in 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

---

From: t.petch <[email-masked]>
Date: Tue, 26 Nov 2013 17:10:44 +0000

mmmmmm

As this I-D says
" A separate,
   incompatible format was defined and published in RFC 6874. "

What it does not say is that RFC6874 has been approved and is on the
Standards Track having passed through all the relevant IETF procedures.
(Nor does it say that you tried to raise this as an erratum, when it
would have been a technical change to that RFC, and so not an erratum!)

My take is that this I-D must not be published as it stands; it can do
nothing but harm to the IETF.  It has to say something about the fact
that it is in contravention of the aforementioned RFC.  Whether that
takes the form of "Updates", applicability statement or what I do not
know; whether it will be possible to achieve consensus on some suitable
form of words, I do not know.

Tom Petch

----- Original Message -----
From: "Michael Sweet" <[email-masked]>
To: "6man" <[email-masked]>
Sent: Friday, November 22, 2013 9:41 PM
Subject: Fwd: New Version Notification for draft-sweet-uri-zoneid-01.txt

> All,
>
> This is my promised second (informational) draft that documents the
usage of the IPvFuture encoding of ZoneID's in URIs for CUPS and IPP in
general.
> > URL:
http://www.ietf.org/internet-drafts/draft-sweet-uri-zoneid-01.txt
> > Status:
http://datatracker.ietf.org/doc/draft-sweet-uri-zoneid
> > Htmlized:
http://tools.ietf.org/html/draft-sweet-uri-zoneid-01
> > Diff:
http://www.ietf.org/rfcdiff?url2=draft-sweet-uri-zoneid-01
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 26 Nov 2013 14:00:51 -0500

Tom,

> would have been a technical change to that RFC, and so not an erratum!)

Correct, and had I known of the existence of the draft that became RFC 6874 I would have argued long and hard against its publication.  But that is water under the bridge and nothing can be done to change that...

> form of words, I do not know.

What harm to the IETF?  Exposing an issue in process where a widely deployed implementation of an abandoned draft could remain unknown by this WG?  Or having someone continue using a draft specification after it was abandoned by the IETF 8 years ago?

As for contravening RFC 6874, I'm not sure I follow.  Certainly it is an alternate syntax to the one chosen for RFC 6874, and one that is in fact referenced in that document.  The security considerations are different to be sure, but if you'll look at the list archive I think you'll see they reflect the discussions after my initial report and subsequent -00 draft.  I would actually argue that RFC 6874 should also be updated accordingly since server-generated link-local URIs were not considered during its development.

Anyways, I was asked to make this an informational document to describe what has been implemented in CUPS based on the URI group's previous work.  I have done so.  I am happy to discuss changes to the document, debate wording, etc. and continue to submit new versions as needed, with the goal of getting it published so that its usage is known.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Nov 2013 08:23:25 +1300

Tom,

I think it is valuable to document this practice, even though it's
incompatible with the standardised syntax.

I would suggest phrasing things a bit differently, however, to make
the situation completely clear without value judgments. Here's a
suggestion for the Abstract; the Introduction would need related changes:

   This document describes how the zone identifier of an IPv6 scoped
   address, defined as <zone_id> in the IPv6 Scoped Address Architecture
   (RFC 4007), is represented for the purposes of the CUPS protocol in a
   Uniform Resource Identifier that includes a literal IPv6 address.  It
   documents a long-standing usage of the IPvFuture extension point
   provided in the Uniform Resource Identifier (URI) syntax specification
   (RFC 3986).  This usage differs from the standard format defined by
   RFC 6874.

The language is intended to be completely non-judgmental, and I have
followed the RFC Editor guideline of not including [citations] in
the Abstract.

Regards
   Brian Carpenter

---

From: t.petch <[email-masked]>
Date: Wed, 27 Nov 2013 09:45:34 +0000

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Michael Sweet" <[email-masked]>; "6man" <[email-masked]>
Sent: Tuesday, November 26, 2013 7:23 PM
>    provided in the Uniform Resource Identifier (URI) syntax
specification
>    (RFC 3986).  This usage differs from the standard format defined by

Brian

Yes, I would support the I-D with that text and its consequential
changes.

I know that when I try to write such things, judgements creep in
unnoticed by me (until long after) which is why I did not try to write a
suitable paragraph myself, trusting that within the IETF we could find a
solution if we wanted to:-)

Tom Petch

> >>>   Uniform Resource Identifier that includes such a literal
address.
> > It

---

From: Michael R Sweet <[email-masked]>
Date: Wed, 27 Nov 2013 06:44:18 -0500

Brian,

I have no objections to your suggested changes to the abstract and will endeavor to mirror them in the introduction.

Question: is it appropriate at all to mention the incompatibilities with RFC 6874 or should I simply say this is different and move on?

Sent from my iPhone

> On Nov 26, 2013, at 2:23 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Tom,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2013 08:11:43 +1300

> Question: is it appropriate at all to mention the incompatibilities with RFC 6874 or should I simply say this is different and move on?

I think that the word 'incompatible' is a bit tricky. If you have two different
branches in the ABNF, leading to two different ways of expressing the same
semantics, they are not in a technical sense incompatible with the ABNF.
Isn't that what we have? I assume one could write a parser that allows both.

6874 forbids transmitting the new syntax outside the host, but it doesn't
forbid the CUPS syntax. So I think in the end, peaceful coexistence should
be possible.

   Brian