Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 ([e-mail] from September 2012)

[Tim Bray <[e-mail]>]

One more data point... I work on Web software all the time and have for
many years; in recent years mostly at the REST (app-to-app HTTP
conversations) rather than browser-wrangling level.  I’d have to say that
URI interoperability problems haven’t come near getting into the list of
top-20 pain points.   So either my experience is wildly untypical, or maybe
it’s a combination of being a little bit lucky, and that the pain which
exists is highly concentrated in the browser space.  -T

On Mon, Oct 22, 2012 at 5:05 PM, Ian Hickson <[e-mail]> wrote:

> On Tue, 23 Oct 2012, Mark Nottingham wrote:
> > On 23/10/2012, at 10:40 AM, Ian Hickson <[e-mail]> wrote:
> > > On Tue, 23 Oct 2012, Mark Nottingham wrote:
> > >>
> > >> Don't much care about the venue, as long as there's *some*
> > >> coordination / communication.
> > >
> > > Everyone is welcome to participate in the WHATWG list.
> >
> > As they are on the IETF list. The difference is that the WHATWG is run
> > by an unelected board of "members" - <http://www.whatwg.org/charter>.
>
> "Run" is a bit of a strong word. There's basically no non-public activity
> from the charter members.
>
>
> > > Anne's spec will define "valid URL", which addressed that need.
> >
> > Why not define (or reuse) a separate term for the input stream, and
> > leave "URL" alone?
>
> Because everyone calls these things URLs (except STD 66).
>
>
> > >> Browser implementers may not care, but it's pretty obvious that lots
> > >> of other people do.
> > >
> > > Browser implementors aren't particularly special here.
> >
> > No, but your arguments are often coloured by your perspective -- just as
> > everyone else's are.
>
> Which arguments in particular are we talking about here? I've mostly been
> talking about curl, wget, GoogleBot, Perl libraries, etc.
>
>
> > If I believed that Anne was willing to and capable of re-specifying
> > RFC3986 in such a way that the definition, syntax and semantics of URLs
> > (or whatever they ends up being called) doesn't change at all, I'd be
> > less concerned.
> >
> > However, that doesn't seem very likely, especially when he isn't
> > engaging with the folks that wrote that spec (especially, Roy).
> >
> > RFC3986 is referenced by a LOT of technologies, not just Web browsers,
> > not just HTML. Replacing it unilaterally with input from the browser /
> > HTML community from an implementer perspective is very likely to break
> > most of them.
>
> I suspect it will break nothing, but I guess we'll find out.
>
> I don't really understand how it _could_ break anything, so long as the
> processing of IRI and URIs as defined by IETF is the same in the WHATWG
> spec, except where software already differs with the IETF specs.
>
> Do you have a concrete example I could study?
>
>
> > As such, they won't use your new spec, and we'll be living in a world
> > where there will be two definitions of "URL" -- the IETF one and the
> > WHATWG one [...].
> >
> > That seems a pretty bad tradeoff for the benefits you're getting -- a
> > slightly easier-to-read spec for browser implementers (a relatively tiny
> > audience).
>
> If you have any concrete concerns, please don't hesitate to e-mail the
> WHATWG list, showing the specific examples you're worried about. Browsers
> are but one of many implementation classes that are relevant.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>