Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI?

Sam Ruby <rubys@intertwingly.net> Fri, 16 January 2015 01:48 UTC

Return-Path: <rubys@intertwingly.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AD71A90A9 for <apps-discuss@ietfa.amsl.com>; Thu, 15 Jan 2015 17:48:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHSLqWwj_g-c for <apps-discuss@ietfa.amsl.com>; Thu, 15 Jan 2015 17:48:51 -0800 (PST)
Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id 8E04E1A8820 for <apps-discuss@ietf.org>; Thu, 15 Jan 2015 17:48:51 -0800 (PST)
Received: from [98.27.51.253] ([98.27.51.253:47549] helo=rubix) by cdptpa-oedge02 (envelope-from <rubys@intertwingly.net>) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 18/72-31347-20E68B45; Fri, 16 Jan 2015 01:48:51 +0000
Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 0E4741409A6; Thu, 15 Jan 2015 20:48:49 -0500 (EST)
Message-ID: <54B86E01.5000607@intertwingly.net>
Date: Thu, 15 Jan 2015 20:48:49 -0500
From: Sam Ruby <rubys@intertwingly.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Larry Masinter <masinter@adobe.com>, "Murray S. Kucherawy" <superuser@gmail.com>
References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <CAKHUCzz=jZAF-i2_pwGpkER5vNhv95CMwdBCMwigPJ0FA_t4_A@mail.gmail.com> <54B7BD4A.1090803@intertwingly.net> <f5ba91kjdt0.fsf@troutbeck.inf.ed.ac.uk> <54B7D851.7060201@intertwingly.net> <CAL0qLwbx3gSr1fJ1iw5QMk3dj2Dm4JMQzsUV_fnr9ef+M2T19g@mail.gmail.com> <54B7E32A.9090800@intertwingly.net> <CAL0qLwbJrcpKhsCAsD_CLAqQQ9rR8GhtpG2xeGO4mGQLriAcYQ@mail.gmail.com> <54B82FD7.9060208@intertwingly.net> <DM2PR0201MB0960CBA360C126703D002895C34E0@DM2PR0201MB0960.namprd02.prod.outlook.com>
In-Reply-To: <DM2PR0201MB0960CBA360C126703D002895C34E0@DM2PR0201MB0960.namprd02.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RR-Connecting-IP: 107.14.168.130:25
X-Cloudmark-Score: 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/JUtEmBhqUy2hgZsm9DlWbA1dQMk>
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jan 2015 01:48:53 -0000

On 01/15/2015 06:30 PM, Larry Masinter wrote:
> +1 BOF at next IETF, whether or not it leads to a working group.
>
> Proposed Agenda: walk through draft-ruby-url-problem (I volunteer)
>                                      based on that, discuss next steps.

Thanks!

> If a working group is wanted, proposed charter milestone:
>
> * finish draft-ruby-url-problem (problem statement agreed or controversies identified, proposed plans concrete or have concrete options), publish as RFC.
> * Then recharter or close (within 4 months)
>
> If you agree, it would help focus the discussion if comments were couched in terms of changes to draft-ruby-url-problem.
> For example, https://tools.ietf.org/html/draft-ruby-url-problem-01#section-5.2  does note some kinds of things an update to 3986 might accomplish, but doesn't suggest changing fragment identifier repertoire, as Sam suggested in email.

I'll ensure that this document is updated before any BOF.

> If you want a mailing list other than appswg, either a new one or an old one; of the existing mailing lists, I suggest uri@w3.org is the closest in scope.
>
> I'm in favor of chartering and managing the work in IETF and not in W3C based on where the specs would get adequate review.
> * URIs/URLs, although invented for the web, are now woven into many other IETF protocols and data structures than the web, and those are mainly out of scope for W3C/WHATWG priorities.
> * it seems easier to get broader review in IETF.  I say this despite the past failure to get W3C/WHATWG participation in the IRI working group, because we now have real data about browser behavior  and the new possibility of getting browser participation in the discussion.

The following section doesn't seem like a good fit for the IETF:

   https://url.spec.whatwg.org/#api

I'd like to understand more why the previous IRI efforts stalled before 
endorsing that part of the work being done at the IETF.

I have no problem with the idea of a RFC 3986bis being done at the IETF.

> Commitments of participation (from W3C management, URL implementors) would help.

I don't think that W3C management will be an issue.

- Sam Ruby