Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard

Mark Nottingham <mnot@mnot.net> Tue, 08 June 2021 06:37 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7943A2450 for <dispatch@ietfa.amsl.com>; Mon, 7 Jun 2021 23:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=l2oENm5p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kTXDu7LW
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 unmc7yE2Jdzx for <dispatch@ietfa.amsl.com>; Mon, 7 Jun 2021 23:37:21 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F923A2467 for <dispatch@ietf.org>; Mon, 7 Jun 2021 23:37:21 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 994F6177D; Tue, 8 Jun 2021 02:37:20 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 08 Jun 2021 02:37:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=I hOwBL6WhQPSLYX3ynZAYoOFlXM4l7oldLgD+2v8EK0=; b=l2oENm5pMp84IgVSz 0bxcjyMR2Ra5veCUGKrsNZlmjm6DhHjogscLUPZyzc+u/ycYiz3vQHfyOEty7/5U tDl7NNoTLgEA5Hlor9YgXuHADAXd9JxOMk5WEUsHiibfdaDqe/GjmrXv89g08Fg9 6hj2ldu0ilqe2RBl00zHygDhAudDE01aMSKR74NafmsFvOSuRS3edHcgqoJTxYTS bTe9SVyo2NaimUY3RKteu9ksYqydtTwj/kJlfh0jaUbfCATawURKbM2rLJMKfwPO +UCA/vxH8Y6Dapj/jvhRiN8jH4z3OrOLDWpF6zEFJVjelqLto8GFcnptfV7khn2v +zTCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=IhOwBL6WhQPSLYX3ynZAYoOFlXM4l7oldLgD+2v8E K0=; b=kTXDu7LWAHpJRwOK7xRe9b7jk1rgJLwx9MZ6caByMSy5jZFOTXz+duGr2 BZO7yTdirPR+zIHTzdAYyNeu3wU733ZUiq5rP9do0j+DKXVK+j534mL7DqeTqzdv t8/hW8UrtQCqk27RZyVo2wXOdFU8gmySgjyy9qkv54H714HPZ5eMRpgiYyhWXWiY PXbOT9EhxQ1OjgYlkY7Qrjs/o7xCjBIXlU2juVjtiLNUMA615wPHd8FEk6QKmGmE ylc5dn4UxE0sjuWrndNpNlUXb7BYlRHt557LXEfOkbjT3m7i8SYLYIlEpRgKRqbZ iVVMvd5NtkUm+DwXj1p4QmJ8PBy+Q==
X-ME-Sender: <xms:HxC_YDTYZMUFUyORsiaX_7vNzj2-oct11meEfoP949AOYcN4xr5C8w> <xme:HxC_YEziFFbMhkIcW0iMTUqc5hALjdJ59BgPhZHRysZKZIDqM6gNXXc9G8mE_tiL- aqcyKRbEPs2v7FpQw>
X-ME-Received: <xmr:HxC_YI36pOflNf5GM9_5V0bZOso7aTErt1lKK96mzxVNm83hW0j_fhwwT5FHq4e3PyewuRaoKwNZEeHEPQd34b5Gm7-hN6zCS21Fpab0NiEATBmfBA8_FWbr>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtkedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothes mhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeeilefghefggfeuieeutdegieeivd elffdulefgiedvtefhkedvleevkefhkeetveenucffohhmrghinhepghhithhhuhgsrdgt ohhmpdhivghtfhdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:HxC_YDDIOF_ro-MxI9_QDSDN5dkGf1iMhmFnVOAIHz2_NKeKI6oOiQ> <xmx:HxC_YMggjPfwfnwfDiLW8w2DBBSytxMybdOUmyUyQ8CyurWX45C9Jw> <xmx:HxC_YHpBZHWddaqgkQ0ltoaZhlNhXA3qg_BPomHKWZVL080GLi1gqw> <xmx:IBC_YEf0AOEIz1-6a5Zeqw6D4fWytez-H4MtNSzeOr0ze_TG8RGNpA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Jun 2021 02:37:17 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <FC052CE1D6FD5CD0B69051AE@PSB>
Date: Tue, 08 Jun 2021 16:37:14 +1000
Cc: Larry Masinter <LMM@acm.org>, dispatch@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BCCD9ABB-9E18-481B-8342-70005966E7E2@mnot.net>
References: <002501d75a5b$08694740$193bd5c0$@acm.org> <FC052CE1D6FD5CD0B69051AE@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/xFbzhV0UG4HpQawDHFo04x_ibPs>
Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2021 06:37:27 -0000

My sense right now is that it's not (yet) appropriate to deprecate 3986/7.

Even if we could ignore the non-Web folks using URIs and IRIs (and there are perhaps good arguments for considering that, IMO, although I know that others have strong feelings, and there's a lot of history here), the current WHATWG specification doesn't specify them -- it specifies how to get from an arbitrary string to what a browser considers a URL to be. It doesn't specify grammar, and it doesn't cover many of the things that 3986 in particular does.

The issue that Larry links to seems to be taking tentative steps towards aligning the grammar in 3986/7 with what WHATWG does, which is great. If that's incorporated, I think there's still a significant gap that would need to be filled before we can deprecate. Even if that gap were to be filled, I question whether the WHATWG is an appropriate home for the specification -- although obviously the W3C has come to peace with HTML living there.

Looking at this from a different angle, we could also ask ourselves whether 3986/7 should be updated to align with WHATWG URL. I think the answer to that is likely to be no -- not only is the delta apparently very small (according to the comments on the linked issue), alignment would mean doing things like considering <> to be valid content in URIs. Again, what they're specifying is how to get from an arbitrary string to a URI, not the syntax itself.

Actually, one useful thing we *could* do would be to replace section 1.1.3 of RFC3986 with something that actually helps people understand the differences between all of these things. If we ceded 'URL' to the WHATWG, leaving 3986 to define URI, it might help.

Cheers,


> On 6 Jun 2021, at 12:21 pm, John C Klensin <john-ietf@jck.com> wrote:
> 
> 
> 
> --On Saturday, June 5, 2021 15:35 -0700 Larry Masinter
> <LMM@acm.org> wrote:
> 
>> Recent progress on WHATWG's URL spec led me to suggest a BOF
>> on the topic for IETF 111
>> 
>> Provide a succinct grammar for valid URL strings
>> <https://github.com/whatwg/url/issues/479> . Issue #479 .
>> whatwg/url (github.com)  
>> 
>> But I didn't get an ack, and perhaps this belongs in
>> DISPATCH/ART etc.
> 
> Larry,
> 
> This is a question rather than a statement of preference because
> I have not thought about it in some time, but are you thinking
> it may be time to either revise or deprecate 3896 and 3897?  I
> may not have enough information but it seems clear to me that,
> in terms of the specs to which implementers are paying
> attention, the action has shifted toward WHATWG (and, to a
> lesser extent, W3C) and away from the IETF documents.
> 
> If deprecating the IETF URI and IRI specs is really the question
> (or part of it), I'd think either a BOF or a well-prepared
> presentation and a rather large block of time in DISPATCH would
> be appropriate.
> 
> best,
>  john
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham   https://www.mnot.net/