Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@xxxxxx from September 2012)

[Tim Bray <tbray@xxxxxxxxxxxxxx>]

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 <ian@xxxxxxxx> wrote:

On Tue, 23 Oct 2012, Mark Nottingham wrote:
> On 23/10/2012, at 10:40 AM, Ian Hickson <ian@xxxxxxxx> 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.   `._.-(,_..'--(,_..'`-.;.'