W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] [url] Feedback from TPAC

From: Anne van Kesteren <annevk@annevk.nl>
Date: Sat, 1 Nov 2014 10:29:03 +0100
Message-ID: <CADnb78hQ1OFtDhmVzUx+EUkc=menygDKSW11wOSer2_s=QUb7A@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: WHATWG <whatwg@whatwg.org>
On Sat, Nov 1, 2014 at 1:01 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> Meanwhile, The IETF is actively working on a update:
> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04
> They are meeting F2F in a little over a week.  URIs in general, and this
> proposal in specific will be discussed, and for that reason now would be a
> good time to provide feedback.  I've only quickly scanned it, but it appears
> sane to me in that it basically says that new schemes will not be viewed as
> relative schemes.

It doesn't say that. (We should perhaps try to find some way to make
"{scheme}://" syntax work for schemes that are not problematic (e.g.
javascript would be problematic). Convincing implementers that it's
worth implementing might be trickier.)

> 1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.

See previous threads on the subject. The data models are incompatible,
at least around "%", likely also around other code points. It also
seems unacceptable to require two parsers for URLs.

> 3) Explicitly state that canonical URLs (i.e., the output of the URL parse
> step) not only round trip but also are valid URIs.  If there are any RFC
> 3986 errata and/or willful violations necessary to make that a true
> statement, so be it.

It might be interesting to figure out the delta. But there are major
differences between RFC 3986 and URL. Not obsoleting the former seems
like a disservice to anyone looking to implement a parser or find
information on URI/URL.

Received on Saturday, 1 November 2014 09:29:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:26 UTC