Re: Options for draft-ietf-6man-uri-zoneid

[t.petch <[e-mail]>]

---- Original Message -----
From: "Juergen Schoenwaelder" <[e-mail]>
To: "Brian E Carpenter" <[e-mail]>; "Benoit Claise"
<[e-mail]>
Cc: "t.petch" <[e-mail]>; "6man" <[e-mail]>
Sent: Friday, May 11, 2012 9:43 AM
> On Fri, May 11, 2012 at 07:56:43AM +0100, Brian E Carpenter wrote:
> > On 2012-05-10 11:39, t.petch wrote:
> > > ---- Original Message -----
> > > From: "Juergen Schoenwaelder" <[e-mail]>
> > > To: "Brian E Carpenter" <[e-mail]>
> > > Cc: "6man" <[e-mail]>
> > > Sent: Tuesday, May 08, 2012 7:34 PM
> > >> On Tue, May 08, 2012 at 03:33:07PM +0100, Brian E Carpenter wrote:
> > >>> I'm not exactly seeing overwhelming consensus, but the loudest
> > >>> virtual hum was for
> > >>>
> > >>>    http://[fe80::a-en1]
> > >>>
> > >>> Advantage: allows use of browser.
> > >>> Disadvantage: doesn't allow simple cut and paste.
> > >>>
> > >>> There was a suggestion to encourage a fix to ping (and traceroute?) to
> > >>> allow the "-" separator, and we must note that in any case, strange
> > >>> characters in the interface ID will always have to be %-encoded.
> > >> I am concerned that the long-term result of this might be that we will
> > >> have to live with both % and - used as separators in various tools and
> > >> interfaces and that this might at the end even cause changes to other
> > >> tools and specifications that currently are just fine with using % as
> > >> a separator. Perhaps I am overly anxious but only future will tell.
> > >
> > > Yes, over the long term I could well see the use of % fading away,
> > > but I would regard that as a good thing:-)
> >
> > Would you want this to be stated as a formal update to RFC 4007?
> >
>
> There are other specifications that use "%" because they follow RFC
> 4007 such as RFC 6021 or RFC 4001 (I am sure there is more but I pick
> these because I know them well ;-). If we do something to the
> separator, I think not only an update to RFC 4007 needs to be
> declared, I think there also needs to be a plan what we do with
> documents such as RFC 6021 or RFC 4001. Is the idea to deprecate all
> those definitions, create new ones, have ripple effects on documents
> using those definitions? RFC 4001, for example, is referenced by 61
> other RFCs - pretty much any recent MIB module representing an IP
> address.
>
> The idea that "%" fades away anytime soon is most likely an illusion.
> If we add "-" as a speparator, all we do is create a situation where
> there are two separators deployed and a situation lasting for many
> many years where some parts only understand "%", some only understand
> "-" and some do both.  The question is whether we are all willing to
> pay this price for enabling zone indexes in URLs and complying to URN
> syntax purity rules.
>
> My understanding is that browsers were able to do what people wanted
> with "%" as a separator - its just that we can standardize this due to
> URL purity rules. Perhaps the real solution here is jump over the URL
> fence and find a way to standardize what browsers were able to do and
> what allowed people to cut and paste. Changing all occurances of "%"
> as a separator in our standards just to comply to URL purity rules may
> get the cost / benefit thing wrong.

For me, it comes in the category of let the market place decide.  I would not
update RFC4007 at this point in time, but if, a few years down the track,
the percent sign has been largely superseded, then yes, I would at that time,
but not before.

Equally, inserting what I take to be a missing 'not' into the paragraph of
Juergen's, it may be that the market place decides that it does not care about
URL purity rules and gives people what they want, what is obviously right to all
but URL purists.  In which case, we update RC3986 in a few years time:-)

So I would go ahead with the I-D in question making Option 3 Normative,
explaining the rejected options in a non-Normative appendix; I see this as the
technically correct, not so user friendly approach, which, having gotten
ourselves to where we are, is the best we can do.  Then the marketplace will
make its choice.  We will, at least, have deprecated what could be worse
options, which might arise if we do nothing.

Tom Petch

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