Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Jul 16, 2012 at 08:03:03AM +0100, Brian E Carpenter wrote:
> Juergen,
> 
> > The "%"
> > separator is also embedded in other IETF standards-track specifications;
> 
> Can you be specific about that? The context here is very specific and
> I am not aware of any other standards that are relevant to IPv6 literals.

RFC 4001 and RFC 6021. These are the ones I have edited. There may be
more. And RFC 4001 seems pretty widely used, pretty much in all more
recent IP related MIB modules:

  http://www.arkko.com/tools/allstats/citations-rfc4001.html

According to 

  http://www.arkko.com/tools/allstats/citations-rfc4007.html

RFC 4007 is used by 9 other RFCs. We could check whether any of the
other 7 RFCs may use a literal IPv6 address format with a zone
identifier.

> There clearly isn't consensus in the WG on a change to the draft that can be
> made before today's cutoff.
> 
> More below:
> 
> On 15/07/2012 17:49, Juergen Schoenwaelder wrote:
> > On Sun, Jul 15, 2012 at 05:19:36PM +0100, Brian E Carpenter wrote:
> >> ... OK, as a result of Dave's comments, we now say:
> >>
> >> "  Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the
> >>    preceding delimiter of a ZoneID."
> >>
> >> What we do *not* say is to recommend or suggest that all tools that
> >> support RFC 4007 should be updated. Should we also add that?
> > 
> > I believe this direction is wrong. Allowing "-" does not replace "%"
> > anytime soon and hence we simply make the problem worse. 
> 
> The problem at the moment is the lack of *uniform* support for ZoneIDs
> in URIs. The cause of that problem is that the delimiter chosen some years
> ago is an escape charater in URIs. IMHO that was a collective error;
> we would never have chosen "$" as the delimiter because everybody knows
> that's an escape character in many CLIs; we just made a mistake by
> overlooking that "%" is also an escape character.
> 
> The WG has already decided to fix this by adding a second delimiter "-".

I am concerned that we are simply too late in the game for changing
this delimiter, in particular if we start allowing both via an update
to RFC 4007.

Also note that RFC 4001 has a DISPLAY-HINT, hence the text in section
1 may be somewhat misleading. On the wire, SNMP ships a number but it
is most likely presented as a rendered value to the user or databases.
RFC 6021 clearly uses a textual format on the wire.

> > The "%"
> > separator is also embedded in other IETF standards-track specifications; I
> > doubt they will all be revised soon to add "-". And then there is of
> > course the question what the canonical format is for comparisions etc.
> 
> Correct, we have added a reference to the IAB draft on this topic, but
> comparison isn't very important for this case because the URIs concerned
> have no meaning outside the originating host.

I am not sure this is generally true. While the interpretation of the
URI is certainly host specific (or even more precise specific to the
nodes' interfaces), this does not necessarily mean those URIs are
never compared outside the host.

> > I believe cut'n'paste from utilities to browsers and back to utilities
> > is desirable (it is not just one direction). All utilities I have
> > understand "%". How many years will cut'n'paste be a hassle if we
> > allow both formats?
> 
> Less than infinity, which is the problem today, since most browsers simply
> can't handle ZoneIDs at all.

If it were that simple, we could simply recommend that browsers should
be lenient and accept the %en1 format. The question is really whether
Internet Explorer people would do so and whether Firefox people would
go back to support what they apparently did before. This would enable
round-trip cut'n'paste and we would be done.
 
> >>From a user experience point of view, the only really sensible thing
> > to do for a browser is to accept %en1 literally. And apparently, this
> > can be done. 
> 
> Or not, according to which browser you consider. Remember that it was
> intentionally removed from Firefox because it violates the URI standard.
> And IE accepts %25en1, so we have an existing incompatibility.

I understand. That is a standardization / implementation issue to
solve.  Solving it by introducing a new notation and pushing the
conversions to users for years to come seems a not very user friendly
resolution.

> > Changing all our standards to support "-" and then
> > waiting years for this to be supported by all the system tools is from
> > a users' perspective pretty much a disaster.
> 
> It is annoying, but seems better than having no solution at all.

I am not even sure about that. The "%" notation works reasonably well
across many applications today. I would be bad if side-effects of an
attempt to settle the URI issue and the desire to support cut'n'paste
at the end causes other things to start disagreeing about the
separator.

Bottom line: I guess my concern mostly boils down to an update of RFC
4007 that allows multiple separators and the effects this might have
by system tools producing and consuming different notations.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>