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

[mike amundsen <[e-mail]>]

<snip>
I’d have to say that URI interoperability problems haven’t come near
getting into the list of top-20 pain points.
</snip>
I can't recall the last time i experienced "URI interoperability problems"
across various user agents/implementations on the public Internet. My
problems w/ browser implementations is another thing.

In this particular case (URIs), I applaud Anne's attempt to fix the broken
way browsers handle these strings within their own executable code (i.e
"browsers (apart from Chrome) do not unescape URL escapes."[1]).

However, I find the announcement that he plans to change the names of
things along the way (i.e. "And yes, the plan is to do away with IRI/URI
and just call them all URLs"[1]) a waste of time.

Fixing the code can happen regardless of naming. Do that and do it now.

Thanks.

[1] http://annevankesteren.nl/2012/09/url-equivalence


mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen


On Mon, Oct 22, 2012 at 8:15 PM, Tim Bray <[e-mail]> wrote:

> 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.   `._.-(,_..'--(,_..'`-.;.'
>>
>
>