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

Ian Hickson <ian@hixie.ch> Tue, 23 October 2012 23:51 UTC

Return-Path: <ian@hixie.ch>
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 8D6C511E810B for <ietf@ietfa.amsl.com>; Tue, 23 Oct 2012 16:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level:
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599]
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 mHODVX5Mg0UO for <ietf@ietfa.amsl.com>; Tue, 23 Oct 2012 16:51:12 -0700 (PDT)
Received: from homiemail-a94.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCDA11E80FE for <ietf@ietf.org>; Tue, 23 Oct 2012 16:51:10 -0700 (PDT)
Received: from homiemail-a94.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a94.g.dreamhost.com (Postfix) with ESMTP id 23A1838A06F; Tue, 23 Oct 2012 16:51:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=d4f8KxGspATkP2rbxqss3qZU3ds=; b=nFF AeW37abDJNo3WgrWliwTmxx+dWV5oNgS9OBE5M5llWfZRj0Iud17E4JCHW5YthxZ 0J7sjGPi/ZmoxYR7GUNKWQrvJwTUbKpoCwfKXZfMKU4qiee9DZPROL9AU4R2Xn+5 ACLJlWeckJr8dmP8cDhdchy9f6pfst9inPOMIul0=
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a94.g.dreamhost.com (Postfix) with ESMTPSA id 036B438A059; Tue, 23 Oct 2012 16:51:09 -0700 (PDT)
Date: Tue, 23 Oct 2012 23:51:09 +0000
From: Ian Hickson <ian@hixie.ch>
To: Christophe Lauret <clauret@weborganic.com>
Subject: Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)
In-Reply-To: <CAGKvQ5ZV6_GMVgjEezhR-oKqSikxR7GYgacMitbfczmNh725mw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1210232348110.2471@ps20323.dreamhostps.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> <CAGKvQ5ZV6_GMVgjEezhR-oKqSikxR7GYgacMitbfczmNh725mw@mail.gmail.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Mailman-Approved-At: Wed, 24 Oct 2012 08:37:10 -0700
Cc: Ted Hardie <ted.ietf@gmail.com>, Jan Algermissen <jan.algermissen@nordsc.com>, 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:51:13 -0000

On Wed, 24 Oct 2012, Christophe Lauret wrote:
> 
> 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.

I think we can agree that the error handling should be, at the option of 
the software developer, either to handle the input as defined by the 
spec's algorithms, or to abort and not handle the input at all.


> But why not do it as a separate spec?

Having multiple specs means an implementor has to refer to multiple specs 
to implement one algorithm, which is not a way to get interoperability. 
Bugs creep in much faster when implementors have to switch between specs 
just in the implementation of one algorithm.


> Increasing the space of valid addresses, when the set of addressable
> resources is not actually increasing only means more complex parsing rules.

I'm not saying we should increase the space of valid addresses. The de 
facto parsing rules are already complicated by de facto requirements for 
handling errors, so defining those doesn't increase complexity either 
(especially if such behaviour is left as optional, as discussed above.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'