Re: [Uri-review] ws: and wss: schemes

"Roy T. Fielding" <fielding@gbiv.com> Thu, 17 September 2009 17:51 UTC

Return-Path: <fielding@gbiv.com>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB233A6BF4; Thu, 17 Sep 2009 10:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.907
X-Spam-Level:
X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=-3.308, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laP+c8IUeN1T; Thu, 17 Sep 2009 10:50:58 -0700 (PDT)
Received: from spaceymail-a5.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id A0D833A6BE2; Thu, 17 Sep 2009 10:50:37 -0700 (PDT)
Received: from [192.168.0.101] (ip72-211-202-154.oc.oc.cox.net [72.211.202.154]) by spaceymail-a5.g.dreamhost.com (Postfix) with ESMTPA id 0F5CC9405F; Thu, 17 Sep 2009 10:51:12 -0700 (PDT)
In-Reply-To: <4AB2109E.3030401@gmx.de>
References: <Pine.LNX.4.62.0908070531430.28566@hixie.dreamhostps.com> <1249651007.25446.8934.camel@dbooth-laptop> <0B450D619CC0486E8BD51C31FBA214AD@POCZTOWIEC> <20090812021926.GC19298@shareable.org> <AB9A0CF094F04D39BC7DC5DEAFF7FC1C@POCZTOWIEC> <4AA8A2CE.3000801@it.aoyama.ac.jp> <34660A8503164BE88641374ADF2BF1A3@POCZTOWIEC> <20090910124618.GB32178@shareable.org> <11DFA16908CB4B7D8AF0F45975DE425A@POCZTOWIEC> <20090910224151.GA17387@shareable.org> <Pine.LNX.4.62.0909170834040.14605@hixie.dreamhostps.com> <4AB205B8.9090005@gmx.de> <Pine.LNX.4.62.0909171012140.20271@hixie.dreamhostps.com> <4AB2109E.3030401@gmx.de>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <69FFAAC3-CEBF-4623-85ED-C12275A89E76@gbiv.com>
Content-Transfer-Encoding: 7bit
From: "Roy T. Fielding" <fielding@gbiv.com>
Date: Thu, 17 Sep 2009 10:51:27 -0700
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.753.1)
Cc: URI <uri@w3.org>, hybi@ietf.org, Ian Hickson <ian@hixie.ch>, uri-review@ietf.org, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Subject: Re: [Uri-review] ws: and wss: schemes
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2009 17:51:03 -0000

On Sep 17, 2009, at 3:34 AM, Julian Reschke wrote:

> Ian Hickson wrote:
>> ...
>>> I meant Section 3.1, which essentially is useless, as it  
>>> replicates what's said in the ABNF in the registration template.
>> The ABNF doesn't say how you parse the URI, it says how you check  
>> if it's valid. Section 3.1 doesn't say how you parse the URI, it  
>> says how you
>
> Actually, unless it's ambiguous, an ABNF *does* define how to parse.

Actually, no, the purpose of an ABNF is to define the grammar for
generating valid strings and testing strings for validity.  It might
be used as a guide by something like lex to create a parser that
enforces validity while parsing, but that generally is not done in
Internet-facing software because of Postel's Law.

For example, RFC 3986 has a very specific grammar for generation
and validity of URIs, but also describes one parsing algorithm
(not the only one, but certainly one in common use) in an
Appendix that will accept any string and parse it into the major
components.

And I'll reiterate, again, that the algorithm for reference parsing
in HTML5 is not definitive of URLs -- it is just a variation on the
appendix in RFC3986 that includes a non-ASCII character encoding
step.  The entire notion that this has anything to do with IRI or URI
definition, or that we need to fix any of the IETF specs to
incorporate browser-specific reference error-handling, is simply
absurd.  They are not the same thing.

....Roy