Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)

Christophe Lauret <clauret@weborganic.com> Tue, 23 October 2012 23:09 UTC

Return-Path: <clauret@weborganic.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85F1F0CAB for <ietf@ietfa.amsl.com>; Tue, 23 Oct 2012 16:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02TJldIcQX3d for <ietf@ietfa.amsl.com>; Tue, 23 Oct 2012 16:09:55 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B86F91F0C3A for <ietf@ietf.org>; Tue, 23 Oct 2012 16:09:55 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so7154664iec.31 for <ietf@ietf.org>; Tue, 23 Oct 2012 16:09:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=aTNLWy+nAYQhy0bjWNyUDByka+Xh/UiDAfKhGeYsZ8E=; b=TikIVzvLssZ+BMZ9Jz2PjOBcetyFd0o7xJ60005yvZ/OInT0vjukwPM3wJvaWGaCKs FnEml+gZ0pScTsSlIt8uFFfs1sxCpJIsViP4IllvPmV8iGaZt2mvSF2UAOJBRdp2Jxsc NND/StKVMjRIsfTygZYDFpfJAIqoRflTLoBkZlDtdP9q3VYlgpfUtWAPxrCEVgcYLNAS QfueCFIjUcA7mZYRy+ycOZSh0Gi+KB2lhS37HNZVNY6alQ96NCGVE3eUqq/OZ9Ay1mI9 aLsAjWcOaenpfmOkpHr+Zs4+kvWlpXj1Mf5FH10K2V+C2GRIVT4F70Mt92AQvhzZadI5 mx6Q==
MIME-Version: 1.0
Received: by 10.50.151.210 with SMTP id us18mr809278igb.1.1351033795247; Tue, 23 Oct 2012 16:09:55 -0700 (PDT)
Received: by 10.64.38.66 with HTTP; Tue, 23 Oct 2012 16:09:54 -0700 (PDT)
In-Reply-To: <15E1D98B-8883-4936-81A9-174E1323683C@nordsc.com>
References: <50604C1A.7090901@gmx.de> <5060A964.5060001@stpeter.im> <Pine.LNX.4.64.1210172354500.2478@ps20323.dreamhostps.com> <507F5A7E.6040206@arcanedomain.com> <50856E3C.103@gmail.com> <Pine.LNX.4.64.1210221753010.2471@ps20323.dreamhostps.com> <0DBC8A11-319C-4120-975E-7E40FD5818BF@gbiv.com> <Pine.LNX.4.64.1210222137530.2471@ps20323.dreamhostps.com> <CA+9kkMDpEZCvcG1DJd=O1qPNV+=+GTBeN+CGndUe51Xym_A9sg@mail.gmail.com> <Pine.LNX.4.64.1210232115210.2471@ps20323.dreamhostps.com> <15E1D98B-8883-4936-81A9-174E1323683C@nordsc.com>
Date: Wed, 24 Oct 2012 10:09:54 +1100
Message-ID: <CAGKvQ5ZV6_GMVgjEezhR-oKqSikxR7GYgacMitbfczmNh725mw@mail.gmail.com>
Subject: Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)
From: Christophe Lauret <clauret@weborganic.com>
To: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: multipart/alternative; boundary="e89a8f3b9e9971ff6f04ccc21148"
X-Gm-Message-State: ALoCoQljSBPTUPAzmU+KbmUb1sROO5lqxC5Bm+FlNBFUsy6IxG2Xa/0E8tLHFYnD2b9r/72GLkpW
X-Mailman-Approved-At: Wed, 24 Oct 2012 08:37:10 -0700
Cc: Ted Hardie <ted.ietf@gmail.com>, Ian Hickson <ian@hixie.ch>, URI <uri@w3.org>, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2012 23:13:41 -0000

Jan wrote:

Help me, I am just not getting it:
> Why do you insist on 'fixing STD 66'?
> What is the reason you are not willing to reframe the problem to 'fixing
> how we get from the provided string -the input to the reference
> construction process- to a STD-66-valid result'?
> To me this is really what you are aiming at and dropping the 'fix the URI
> spec' language would get everyone on board immediately in my perception.


I completely agree - I don't understand the insistence on "fixing" STD 66.

As a Web developer who's had to write code multiple times to handle URIs in
very different contexts, I actually *like* the constraints in STD 66, there
are many instances where it is simpler to assume that the error handling
has been done prior and simply reject an invalid URI. By reducing the space
of valid addresses around rigid rules to match more closely the set of
addressable resources, it reduces my scope of work.

I understand that it isn't practical in some contexts (e.g. browsers) where
it is inevitable that strings that are not considered valid URI references
will crop up and it is desirable for everyone to deal with these in a
consistent manner. So, I applaud Anne and Ian for wanting to standardize
the error handling and tackling this problem head on.
But why not do it as a separate spec?

Increasing the space of valid addresses, when the set of addressable
resources is not actually increasing only means more complex parsing rules.
I accept that it is a requirement in some contexts, but it is
also completely unnecessary in others where coding against STD 66 is just
fine if not more desirable.

Personally, I don't have any qualms in calling that larger set of addresses
"URLs" if it is what most people use, and leave STD 66 and URIs are as they
are.

Christophe-

(I've used 'address' as a short for a "string which should ultimately
resolve as a valid STD 66 result")