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

[Juergen Schoenwaelder <[e-mail]>]

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.

/js

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