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

The question is: is there enough interest to have a BOF at IETF 111 to
discuss
a plan for moving forward? I don't imagine starting out with a presentation
of
a solution. 

  I'd probably want to focus on "minimum viable product":
What things could we do first with minimum effort that would improve the
current state?  A replacement for RFCs 3986 and 3987 wouldn't be my
first step. Maybe a short standards-track "UPDATES" that points to/contains
deltas or a new grammar that is more consistent with (tested)
implementations.
And a pointer to WHATWG-URL, whether normative or not I'm not sure.

That's a little more than Mark's "Section 1.1.3" because it makes normative
changes but (apparently) minimal ones.

I was encouraged to see WHATWG paying attention to feedback from curl
and node.js as implementations of URLs, not just browsers.

Larry
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: Mark Nottingham <mnot@mnot.net>
> Sent: Monday, June 7, 2021 11:37 PM
> To: John C Klensin <john-ietf@jck.com>
> Cc: Larry Masinter <LMM@acm.org>; dispatch@ietf.org
> Subject: Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard
> 
> 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/