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

Roberto Peon <grmocg@gmail.com> Thu, 25 October 2012 17:45 UTC

Return-Path: <grmocg@gmail.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 2E72221F889E for <ietf@ietfa.amsl.com>; Thu, 25 Oct 2012 10:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[AWL=-3.507, BAYES_00=-2.599, 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 5SgFlCXaZlRR for <ietf@ietfa.amsl.com>; Thu, 25 Oct 2012 10:45:49 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA04E21F888D for <ietf@ietf.org>; Thu, 25 Oct 2012 10:45:48 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so1974853lam.31 for <ietf@ietf.org>; Thu, 25 Oct 2012 10:45:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hg2lHCReEa5/yZKL7di74y0Lf2hijv2Xr63fPSkgPnw=; b=OPhksayqgTQ4FoRoyvIbxGWcnOLhczvKvMaFf05mS7wHr6nb9WYaYuM27Oi0DnAIlO v3g96WKCdk+BrRDR3dbOBR1w5YRcj6ZfOQaSX/0FzebgqyZYMHH6DhV7/H6iHfD6orb3 IP0y1o73b5et2cAMI0HErmdw+6LDOxtOMWbfRc6BLwIJMGtKjmcsz+XVLJt3ttD00TRU J55MVd7E3+pZo7oh+XWPgWaduGDJQUHbKthv/PyIAe8JITGsjFzM7WKjv1ek5sRNA+Xx qmOXkSmLqngKYlgujQ5fyyDQ0YIw+kvxcRecp4pCcBRek1xBMkhvURcUssemGPIjgLvr 67zg==
MIME-Version: 1.0
Received: by 10.112.30.65 with SMTP id q1mr7435436lbh.83.1351187147700; Thu, 25 Oct 2012 10:45:47 -0700 (PDT)
Received: by 10.114.39.113 with HTTP; Thu, 25 Oct 2012 10:45:47 -0700 (PDT)
Received: by 10.114.39.113 with HTTP; Thu, 25 Oct 2012 10:45:47 -0700 (PDT)
In-Reply-To: <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> <Pine.LNX.4.64.1210232348110.2471@ps20323.dreamhostps.com>
Date: Thu, 25 Oct 2012 10:45:47 -0700
Message-ID: <CAP+FsNdkYyZ0DMJ2jz+Yh6uSSGSV=BH5hfspsdXcXEzDpc83DA@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: Roberto Peon <grmocg@gmail.com>
To: Ian Hickson <ian@hixie.ch>
Content-Type: multipart/alternative; boundary="bcaec55401c4f6b96304cce5c5e1"
Cc: URI <uri@w3.org>, Jan Algermissen <jan.algermissen@nordsc.com>, Christophe Lauret <clauret@weborganic.com>, Ted Hardie <ted.ietf@gmail.com>, 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: Thu, 25 Oct 2012 17:45:50 -0000

There are obviously orthogonal problems here.
If we were doing this as code, these would be separate functions and most
everyone would agree that it would make both testing and understanding
easier.

Why is it different with specs? The hardest part of specs is choosing which
one is right. The second hardest part is dealing with ambiguity (and the
larger the function, the more difficult figuring out intention, at least
IMHO)

-=R
On Oct 24, 2012 8:44 AM, "Ian Hickson" <ian@hixie.ch> wrote:

> 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.   `._.-(,_..'--(,_..'`-.;.'
>