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

Jan Algermissen <jan.algermissen@nordsc.com> Tue, 23 October 2012 22:52 UTC

Return-Path: <jan.algermissen@nordsc.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 A0FBE1F0C95 for <ietf@ietfa.amsl.com>; Tue, 23 Oct 2012 15:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.646
X-Spam-Level:
X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 TMoPCV7IMNJP for <ietf@ietfa.amsl.com>; Tue, 23 Oct 2012 15:52:44 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 52AC21F0C3A for <ietf@ietf.org>; Tue, 23 Oct 2012 15:52:44 -0700 (PDT)
Received: from [192.168.2.103] (p548FAD1A.dip.t-dialin.net [84.143.173.26]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MIAjy-1TRKVC3okw-004OYd; Wed, 24 Oct 2012 00:52:41 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <Pine.LNX.4.64.1210232234590.2471@ps20323.dreamhostps.com>
Date: Wed, 24 Oct 2012 00:52:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CC5FA04-2F61-408F-AED5-792E086E9BA0@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> <Pine.LNX.4.64.1210232234590.2471@ps20323.dreamhostps.com>
To: Ian Hickson <ian@hixie.ch>
X-Mailer: Apple Mail (2.1499)
X-Provags-ID: V02:K0:SUm83kQs02Oxz12SR6kBrY48ScbXHt78CvBPgL2E8DB Vl7nyzkZNgwekNA5F0/U2u/E5U5veNmDVT8xi0xncrQgAEYxPo D50hpntDmPEU3YJdTNzhyDLLc8oGwH1T//kbjm0JzJXTn2dsPx LTlYxj0PSEW1eUQB6wKDE3AXm62/yqX43+GNdqJBn8vua+CEuh dXYx4ESjJla2hO4Ez57IWrU+Lvy7Jpoahm18EmfgtoYbvJ7OTY Sh4qVMkd0khU/NggdZ57q7JgclzTslzIkrXflq4BGgUpPqn6t+ LweJxZn/yJkiYwXaaI107CyTY1VP+VUEcf2/5s9PCWOSwF9Kg+ dHF4nCGhBZPiWSbc0CNVb9Cfng7s5Vg2KWlwuPYRNCJTuNQFrw 3SjBrWJSLbrrw==
X-Mailman-Approved-At: Wed, 24 Oct 2012 08:37:10 -0700
Cc: Ted Hardie <ted.ietf@gmail.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 22:52:45 -0000

On Oct 24, 2012, at 12:43 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 23 Oct 2012, Jan Algermissen wrote:
>> On Oct 23, 2012, at 11:34 PM, Ian Hickson <ian@hixie.ch> wrote:
>>> 
>>> Let's in fact try: Hi guys, we need to fix STD 66 because it doesn't 
>>> define error handling.
>> 
>> 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'?
> 
> Because that's not a good way to write specs. Implementors shouldn't have 
> to read three separate specs to implement one algorithm. The definition 
> for Base64 isn't spread into tree separate RFCs. You don't put the HTML 
> parser in a different spec than the HTML elements.
> 
> A spec for this kind of thing should define the following:

Then, how about going from 'fixing STD 66' to

'augmenting STD 66 with how we get from the provided string -the input to the reference construction process- to a valid URI'?


(Personally, I do not see any problems with having one spec defining the valid output and one spec defining how to get from input to valid output. But that is a discussion that can be easily separated from the current one.)

What matters is that nothing of the existing URI spec *changes*.

Can you agree on that?

Jan


> 
> - The conformance requirements for authors so that they can use the 
>   technology in a manner that avoids likely pitfalls
> 
> - A processing model for each relevant implementation conformance class 
>   (software) that defines how you take the input and use it
> 
> In the case of these string, that means, to a first approximation:
> 
> - A definition of what the valid syntax of these strings is.
> 
> - A definition of how you get from one of these strings, whether valid or 
>   not, to the information you need to process it, in particular, for 
>   e.g. strings that reference specific files:
>    - the scheme (what protocol you're going to be using)
>    - the hostname and port of the remote host
>    - the path and query string to pass to that host
>    - the fragment identifier
> 
> So there should just be one spec, not three (IRIs, URIs, and the error 
> handling).
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'