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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
86 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
FYI:

Quoting AvK in
<http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0297.html>:

> The plan is to obsolete the RFCs. But yes, I will add some references
> in the Goals section most likely. Similar to what has been done in the
> DOM Standard.

Note this is about RFC 3986, which is a Full Standard.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Peter Saint-Andre-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/24/12 6:03 AM, Julian Reschke wrote:

> FYI:
>
> Quoting AvK in
> <http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0297.html>:
>
>
>> The plan is to obsolete the RFCs. But yes, I will add some
>> references in the Goals section most likely. Similar to what has
>> been done in the DOM Standard.
>
> Note this is about RFC 3986, which is a Full Standard.

Hi Julian,

It's not completely clear to me what Anne meant there by saying "the
plan is to obsolete the RFCs" (naturally that is not something that
anyone outside the IETF can do, although they can ignore the RFCs).
It's also not clear to me what the WHATWG HTML Living Standard [1]
really means by "willful violation" [2] -- e.g., is it just an
allowance for APIs and browser software to not be completely strict
about processing some input for the sake of backward compatibility
with existing (messy) web content, or is it an active attempt at
redefining core protocols? However, it is interesting that the willful
violations are not limited to RFC 3986: the spec also mentions willful
violations of RFC 2046, RFC 2616, RFC 2781, RFC 5322, EcmaScript,
XPath, XSLT, and Unicode. Quite a list...

Peter

[1] http://www.whatwg.org/specs/web-apps/current-work/

[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#willful-violation

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBgqWQACgkQNL8k5A2w/vxD/QCeNTDVz/kaXkhROIm1/N9QB5Tf
QroAoPI96pCgHUCnjZqGLjmCrqLBQ1ym
=Nscu
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

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

sm-7
At 11:41 24-09-2012, Peter Saint-Andre wrote:
>It's not completely clear to me what Anne meant there by saying "the
>plan is to obsolete the RFCs" (naturally that is not something that
>anyone outside the IETF can do, although they can ignore the RFCs).
>It's also not clear to me what the WHATWG HTML Living Standard [1]
>really means by "willful violation" [2] -- e.g., is it just an

The following message was posted over a year ago:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03064.html

Regards,
-sm



Reply | Threaded
Open this post in threaded view
|

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

John C Klensin


--On Monday, September 24, 2012 22:51 +0100 Brian E Carpenter
<[hidden email]> wrote:

>...
> Some of the "violations" are "motivated by a desire to handle
> legacy content". That seems to be in the IETF spirit of "Be
> strict when sending and tolerant when receiving" for the sake
> of backwards compatibility. Any of them that damage
> interoperability and compatibility would be more worrisome.

And some of it isn't.  As just one example, opinions may differ
about whether it is reasonable to impose restrictions on valid
email addresses because some legacy implementations did a sloppy
job, but one certainly cannot justify it on the basis of the
Robustness Principle.

    john





Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson
In reply to this post by Peter Saint-Andre-2
On Mon, 24 Sep 2012, Peter Saint-Andre wrote:
>
> It's also not clear to me what the WHATWG HTML Living Standard [1]
> really means by "willful violation"
> http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#willful-violation

Can you elaborate on how the definition you cite there in the spec is
unclear? I'm not sure how to make it clearer.


> e.g., is it just an allowance for APIs and browser software to not be
> completely strict about processing some input for the sake of backward
> compatibility with existing (messy) web content, or is it an active
> attempt at redefining core protocols?

The spec seems pretty clear that it's the latter ("conflicting needs have
led to this specification violating the requirements of these other
specifications").


> However, it is interesting that the willful violations are not limited
> to RFC 3986: the spec also mentions willful violations of RFC 2046, RFC
> 2616, RFC 2781, RFC 5322, EcmaScript, XPath, XSLT, and Unicode. Quite a
> list...

Yeah. Turns out we (the Web standards community) haven't been doing such a
great job of making our specificatiosn match reality. :-(

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

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

Noah Mendelsohn


On 10/17/2012 7:57 PM, Ian Hickson wrote:
> Yeah. Turns out we (the Web standards community) haven't been doing such a
> great job of making our specificatiosn match reality.:-(

Um, true... but it's also the case that the implementation community hasn't
over the years been doing as much as might be best to make reality match
the specifications. The new specs we're writing now would like have been a
lot thinner and cleaner if they had.

Noah

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson
On Wed, 17 Oct 2012, Noah Mendelsohn wrote:
> On 10/17/2012 7:57 PM, Ian Hickson wrote:
> > Yeah. Turns out we (the Web standards community) haven't been doing
> > such a great job of making our specificatiosn match reality.:-(
>
> Um, true... but it's also the case that the implementation community
> hasn't over the years been doing as much as might be best to make
> reality match the specifications. The new specs we're writing now would
> like have been a lot thinner and cleaner if they had.

At least on the browser front, having been on those front lines for much
of my career, I don't really know what more we could have done.

But in any case, that's somewhat irrelevant now, since it's too late to
ge back and change it.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson
In reply to this post by Noah Mendelsohn
On Mon, 22 Oct 2012, Brian E Carpenter wrote:

> On 18/10/2012 02:25, Noah Mendelsohn wrote:
> > On 10/17/2012 7:57 PM, Ian Hickson wrote:
> >> Yeah. Turns out we (the Web standards community) haven't been doing
> >> such a great job of making our specificatiosn match reality.:-(
> >
> > Um, true... but it's also the case that the implementation community
> > hasn't over the years been doing as much as might be best to make
> > reality match the specifications. The new specs we're writing now
> > would like have been a lot thinner and cleaner if they had.
>
> However, I think the concern here is that if certain IETF specs need to
> be updated to match the real world, that work needs to be done in the
> IETF.

I couldn't agree more! We've been waiting for four years for the URI
working group to get their act together and fix the URL mess. Nothing has
happened. We lost patience and are now doing it ourselves.

I'm sure Anne would love nothing more than to be able to work on something
more interesting that this. But at the end of the day, someone has to do
it, and y'all aren't doing it.

This should not come as a surprise to anyone, the IETF and W3C have been
discussing this matter at last as far back as 2008.


> It can't be done by reference in a W3C document; it has to be done by
> value in an IETF document.

Currently it's only being done in a WHATWG document.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

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

Noah Mendelsohn
On Mon, 22 Oct 2012, Brian E Carpenter wrote:
 > On 18/10/2012 02:25, Noah Mendelsohn wrote:
 >> On 10/17/2012 7:57 PM, Ian Hickson wrote:
 >>> Yeah. Turns out we (the Web standards community) haven't been doing
 >>> such a great job of making our specificatiosn match reality.:-(
 >>
 >> Um, true... but it's also the case that the implementation community
 >> hasn't over the years been doing as much as might be best to make
 >> reality match the specifications. The new specs we're writing now
 >> would like have been a lot thinner and cleaner if they had.
 >
 > However, I think the concern here is that if certain IETF specs need to
 > be updated to match the real world, that work needs to be done in the
 > IETF.

That's certainly an important concern, but it's not the one I had in mind
when I made my comment.

Rather, while Ian is right that our new specifications must match today's
"reality", we should also be sobered by the price we're paying for years of
implementations that do things like sniffing. Yes, given that it's become
widespread, documenting ways to do it interoperably and securely is good.
I'm not convinced that implementing sniffing in widely-used user agents was
the right choice way back when.

So, let's try harder than we have in the past to not introduce yet more
such cruftiness, even if we do have to document what's there. Maybe we
should have been a little more hesitant to do things like having both SVG
and Canvas as ways of doing graphics. Perhaps that overlapping function is
ultimately justified, but there's a long term cost. We're moving too far
away from KISS IMO.

HTML5 is great work, but the spec is very, very thick. Keeping things as
small and simple as we can moving forward is really what I had in mind.

Noah

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Ian Hickson
On 2012-10-22 19:55, Ian Hickson wrote:

> On Mon, 22 Oct 2012, Brian E Carpenter wrote:
>> On 18/10/2012 02:25, Noah Mendelsohn wrote:
>>> On 10/17/2012 7:57 PM, Ian Hickson wrote:
>>>> Yeah. Turns out we (the Web standards community) haven't been doing
>>>> such a great job of making our specificatiosn match reality.:-(
>>>
>>> Um, true... but it's also the case that the implementation community
>>> hasn't over the years been doing as much as might be best to make
>>> reality match the specifications. The new specs we're writing now
>>> would like have been a lot thinner and cleaner if they had.
>>
>> However, I think the concern here is that if certain IETF specs need to
>> be updated to match the real world, that work needs to be done in the
>> IETF.
>
> I couldn't agree more! We've been waiting for four years for the URI
> working group to get their act together and fix the URL mess. Nothing has
> happened. We lost patience and are now doing it ourselves.
> ...

Clarifying: there is no URI Working Group, and as far as I can tell,
there is no consensus that there is a "mess" to fix related to URIs.
There *is* indeed a *IRI* Working Group which planned to define things
that occur in HTML links (including sanitizing whitespace and dealing
with the problems with non-ASCII characters), and *that* WG indeed
hasn't delivered yet.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Roy T. Fielding
In reply to this post by Ian Hickson
On Oct 22, 2012, at 10:55 AM, Ian Hickson wrote:

> On Mon, 22 Oct 2012, Brian E Carpenter wrote:
>> On 18/10/2012 02:25, Noah Mendelsohn wrote:
>>> On 10/17/2012 7:57 PM, Ian Hickson wrote:
>>>> Yeah. Turns out we (the Web standards community) haven't been doing
>>>> such a great job of making our specificatiosn match reality.:-(
>>>
>>> Um, true... but it's also the case that the implementation community
>>> hasn't over the years been doing as much as might be best to make
>>> reality match the specifications. The new specs we're writing now
>>> would like have been a lot thinner and cleaner if they had.
>>
>> However, I think the concern here is that if certain IETF specs need to
>> be updated to match the real world, that work needs to be done in the
>> IETF.
>
> I couldn't agree more! We've been waiting for four years for the URI
> working group to get their act together and fix the URL mess. Nothing has
> happened. We lost patience and are now doing it ourselves.

What you are insisting on defining as a "URL" is the input to the
process of making a hypertext reference (the arbitrary string typed
into a dialog or placed inside an href/src attribute), whereas the
IETF standards define the output of that process as a uniform
addressing syntax for use on the Internet by every application that
makes use of Web addresses.  Browsers implement both the input
processing and the output URI standards.  HTML must define the
input processing, either within the spec or by reference to a
new spec. The IETF defined the output standards for what goes
on the wire.

I would love to have a single standard for hypertext references.
However, they are not URLs, they are not implemented consistently
across HTML elements, and even within single elements they are
not implemented consistently across browsers.  It is a worthwhile
area to pursue further consistency, but only if you stop referring
to them as something they are not and never will be. "" is not a URL.

> I'm sure Anne would love nothing more than to be able to work on something
> more interesting that this. But at the end of the day, someone has to do
> it, and y'all aren't doing it.
>
> This should not come as a surprise to anyone, the IETF and W3C have been
> discussing this matter at last as far back as 2008.

Yes, we have been discussing it since 1994.  It would be nice
if you would take the advice already received and define
references in HTML, including the algorithms for converting them
into URI references (for DOM and network usage) and IRI
references (for display).

There is no need for any willful violations, since you aren't
even defining the same things.

....Roy


Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson
On Mon, 22 Oct 2012, Julian Reschke wrote:
> >
> > I couldn't agree more! We've been waiting for four years for the URI
> > working group to get their act together and fix the URL mess. Nothing
> > has happened. We lost patience and are now doing it ourselves. ...
>
> Clarifying: there is no URI Working Group, and as far as I can tell,

Whoever. The people complaining that it should be done at the IETF haven't
done any work. That's the complaint. Until they do the work, complaining
that we're doing it instead is going to fall on deaf ears and be met with
the rolling of eyeballs.


> there is no consensus that there is a "mess" to fix related to URIs.

The specs don't define everything that implementations have to do to be
interoperable. If the IETF doesn't think that's a problem, then that's
fine, but then y'all shouldn't be surprised when people who _do_ think
that's a problem try and fix it.


On Mon, 22 Oct 2012, Roy T. Fielding wrote:
>
> What you are insisting on defining as a "URL" is the input to the
> process of making a hypertext reference (the arbitrary string typed into
> a dialog or placed inside an href/src attribute)

Or placed on a command line to wget(1), or put in an RDFa triple store, or
in transmitted in an HTTP Location: header, or...


> whereas the IETF standards define the output of that process as a
> uniform addressing syntax for use on the Internet by every application
> that makes use of Web addresses.

That's what Anne is specifying, because, despite your claims, STD 66
doesn't actually define that. It only defines processing for valid
strings, not invalid ones.


> Browsers implement both the input processing and the output URI
> standards.  HTML must define the input processing, either within the
> spec or by reference to a new spec.

This has nothing particularly to do with HTML, HTML is just one of many
many contexts in which URLs are found.


> "" is not a URL.

Whether it's a valid URL or not is besides the point (it's like people
claiming that invalid XML files aren't XML, a pointless argument). We
still have to define the processing for such a string when software is to
process it as a URL.


> > I'm sure Anne would love nothing more than to be able to work on
> > something more interesting that this. But at the end of the day,
> > someone has to do it, and y'all aren't doing it.
> >
> > This should not come as a surprise to anyone, the IETF and W3C have
> > been discussing this matter at last as far back as 2008.
>
> Yes, we have been discussing it since 1994.

19 years of not fixing the problem, then. Shouldn't come as a surprise
that someone has finally gotten around to doing it.


> It would be nice if you would take the advice already received and
> define references in HTML, including the algorithms for converting them
> into URI references (for DOM and network usage) and IRI references (for
> display).

As far as HTML goes, my plan is to remove all references to STD 66 and
rely entirely on Anne's work, so that there doesn't have to be any
preprocessing nonsense. Then the STD 66 RFCs are entirely irrelevant.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

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

Jan Algermissen-3
Ian,

On Oct 22, 2012, at 11:46 PM, Ian Hickson wrote:

>> "" is not a URL.
>
> Whether it's a valid URL

the question if not whether an empty string is a valid URI.

The point is that what you and Anne are addressing is parsing of URI *References* not URIs.

Roy, IIUC, meant that "" is a URI *reference* - it is not a valid or invalid URI.

This is why any references to fixing or aligning URI syntax with reality is besides the point and not neccessary. All that you (we) deal with is URI references and how to parse them to yield valid URIs.


Jan



Reply | Threaded
Open this post in threaded view
|

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

Tim Bray-3
In reply to this post by Ian Hickson
On Mon, Oct 22, 2012 at 2:46 PM, Ian Hickson <[hidden email]> wrote:

> On Mon, 22 Oct 2012, Roy T. Fielding wrote:
>>
>> What you are insisting on defining as a "URL" is the input to the
>> process of making a hypertext reference (the arbitrary string typed into
>> a dialog or placed inside an href/src attribute)
>
> Or placed on a command line to wget(1), or put in an RDFa triple store, or
> in transmitted in an HTTP Location: header, or...

It seems reasonable that someone should write rules for dealing with the kinds of errors that are observed to occur in links as embedded in resource representations AKA HTML pages.  It also seems reasonable that WHATWG, who speak (if I understand correctly) for browser builders, can write those rules.

The notion that curl, or an HTTP cache manager, or an XML namespace processor, is going to be routing around errors, strikes me on the face of it as being wrong.  One of the main uses I put curl to is making sure I have the URL exactly right before I drop it into chat or whatever.   -T


Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
In reply to this post by Ian Hickson
On 2012-10-22 23:46, Ian Hickson wrote:

> On Mon, 22 Oct 2012, Julian Reschke wrote:
>>>
>>> I couldn't agree more! We've been waiting for four years for the URI
>>> working group to get their act together and fix the URL mess. Nothing
>>> has happened. We lost patience and are now doing it ourselves. ...
>>
>> Clarifying: there is no URI Working Group, and as far as I can tell,
>
> Whoever. The people complaining that it should be done at the IETF haven't
> done any work. That's the complaint. Until they do the work, complaining
> that we're doing it instead is going to fall on deaf ears and be met with
> the rolling of eyeballs.

This always was about venue, not people. If people want to "fix" or
"augment" URIs/IRIs, they should come over to the IETF. That's where the
specs live. The IETF is open to anyone, works async on mailing lists,
and doesn't require any membership fees. I don't think there's any
standards body that is *more* open to individuals.

But yes, you may have to convince a few people outside the WhatWG.
That's a feature. It means more review from people outside the browser
ecosystem.

>> there is no consensus that there is a "mess" to fix related to URIs.
>
> The specs don't define everything that implementations have to do to be
> interoperable. If the IETF doesn't think that's a problem, then that's
> fine, but then y'all shouldn't be surprised when people who _do_ think
> that's a problem try and fix it.

Yes, please fix *that*, but *just* that without messing with the basics
without consensus/review.

So yes: if you feel you need to make \ to equivalent to /, that may be
ok (as \ isn't valid anyway). But changing the reference resolution
algorithm for valid URI/reference pairs is something entirely different.
*If* it needs to be done, it needs to be done within the scope of the
URI spec.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

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

Mark Nottingham-2
In reply to this post by Tim Bray-3

On 23/10/2012, at 9:11 AM, Tim Bray <[hidden email]> wrote:

> It seems reasonable that someone should write rules for dealing with the kinds of errors that are observed to occur in links as embedded in resource representations AKA HTML pages.  It also seems reasonable that WHATWG, who speak (if I understand correctly) for browser builders, can write those rules.

+1. The work seems obviously necessary, the confusion is around why this is being couched in terms of redefining URIs, rather than just defining it as "how you get to a URI (or an unrecoverable error) from an arbitrary string."

Cheers,

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




Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson
In reply to this post by Julian Reschke
On Tue, 23 Oct 2012, Jan Algermissen wrote:
>
> The point is that what you and Anne are addressing is parsing of URI
> *References* not URIs.

Anne's spec defines how you get from any arbitrary string (plus a base
URL) to a data structure with fields like scheme, hostname, port, path,
etc. The input can be absolute, completely invalid, the empty string,
whatever.


> This is why any references to fixing or aligning URI syntax with reality
> is besides the point and not neccessary. All that you (we) deal with is
> URI references and how to parse them to yield valid URIs.

That's certainly part of the required work, yes. It's not all of it.


On Mon, 22 Oct 2012, Tim Bray wrote:
>
> The notion that curl, or an HTTP cache manager, or an XML namespace
> processor, is going to be routing around errors, strikes me on the face
> of it as being wrong.  One of the main uses I put curl to is making sure
> I have the URL exactly right before I drop it into chat or whatever.  

   $ wget 'http://example.com/a b'
   --2012-10-23 00:27:43--  http://example.com/a%20b

   # test.cgi returns a 301 with "Location: a b"
   $ curl -L http://damowmow.com/playground/demos/url/in-http-headers/test.cgi
   This file is: http://damowmow.com/playground/demos/url/in-http-headers/a%20b

Software does this stuff already. We need to make sure it does it
interoperably.


On Tue, 23 Oct 2012, Julian Reschke wrote:
>
> This always was about venue, not people. If people want to "fix" or
> "augment" URIs/IRIs, they should come over to the IETF.

I think the person doing the work has the prerogative to do it wherever he
or she wants to do it. Maybe the IETF should consider why Anne isn't doing
it in the IETF.


> > The specs don't define everything that implementations have to do to
> > be interoperable. If the IETF doesn't think that's a problem, then
> > that's fine, but then y'all shouldn't be surprised when people who
> > _do_ think that's a problem try and fix it.
>
> Yes, please fix *that*, but *just* that without messing with the basics
> without consensus/review.

Consensus isn't a value I hold highly, but review of Anne's work is
welcome.

If the IETF community didn't want Anne to do this work, then the IETF
community should have done it. Having not done it, having not even
understood that the problem exists, means the IETF has lost the
credibility it needs to claim that this is in the IETF's domain.

You don't get to claim authority over an area while at the same time
telling someone else "please fix that" for the hard work that comes with
that area. The reality is, he who does the hard work, gets the authority.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

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

Mark Nottingham-2

On 23/10/2012, at 9:35 AM, Ian Hickson <[hidden email]> wrote:

> Consensus isn't a value I hold highly, but review of Anne's work is
> welcome.
>
> If the IETF community didn't want Anne to do this work, then the IETF
> community should have done it. Having not done it, having not even
> understood that the problem exists, means the IETF has lost the
> credibility it needs to claim that this is in the IETF's domain.
>
> You don't get to claim authority over an area while at the same time
> telling someone else "please fix that" for the hard work that comes with
> that area. The reality is, he who does the hard work, gets the authority.

All very interesting, but please address the point that's now been made repeatedly -- why is it necessary for you to redefine URIs, rather than doing as we suggest?

Regards,

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




Reply | Threaded
Open this post in threaded view
|

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

James M Snell
In reply to this post by Ian Hickson


On Mon, Oct 22, 2012 at 3:35 PM, Ian Hickson <[hidden email]> wrote:
On Tue, 23 Oct 2012, Jan Algermissen wrote:
>
> The point is that what you and Anne are addressing is parsing of URI
> *References* not URIs.

Anne's spec defines how you get from any arbitrary string (plus a base
URL) to a data structure with fields like scheme, hostname, port, path,
etc. The input can be absolute, completely invalid, the empty string,
whatever.


Sounds useful but does not sound really like Anne's spec is "defining URLs", however. Clarifying the language in your spec ought to resolve any possible confusion. 
 

> This is why any references to fixing or aligning URI syntax with reality
> is besides the point and not neccessary. All that you (we) deal with is
> URI references and how to parse them to yield valid URIs.

That's certainly part of the required work, yes. It's not all of it.


Is there a list of issues that you and Anne are working from for this? If there indeed is a need to update the URI/IRI RFC's to address specific problems I'm sure it wouldn't take much effort to draft up an I-D. I'd be more than willing to help out with such an effort.
 
[snip]
I think the person doing the work has the prerogative to do it wherever he
or she wants to do it. Maybe the IETF should consider why Anne isn't doing
it in the IETF.


Indeed. Good question: Anne, is there are particular reason why you chose not to pursue this work as an I-D? Let's get that particular issue resolved.

- James
 

> > The specs don't define everything that implementations have to do to
> > be interoperable. If the IETF doesn't think that's a problem, then
> > that's fine, but then y'all shouldn't be surprised when people who
> > _do_ think that's a problem try and fix it.
>
> Yes, please fix *that*, but *just* that without messing with the basics
> without consensus/review.

Consensus isn't a value I hold highly, but review of Anne's work is
welcome.

If the IETF community didn't want Anne to do this work, then the IETF
community should have done it. Having not done it, having not even
understood that the problem exists, means the IETF has lost the
credibility it needs to claim that this is in the IETF's domain.

You don't get to claim authority over an area while at the same time
telling someone else "please fix that" for the hard work that comes with
that area. The reality is, he who does the hard work, gets the authority.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson
On Mon, 22 Oct 2012, James M Snell wrote:
>
> Is there a list of issues that you and Anne are working from for this?
> If there indeed is a need to update the URI/IRI RFC's to address
> specific problems I'm sure it wouldn't take much effort to draft up an
> I-D. I'd be more than willing to help out with such an effort.

See the spec. He's documented what needs to be done. The big one that he
hasn't done yet is defining "valid URL" (the "Writing" section), which is
the bulk of what STD 66 and the IRI RFC do.


> > Maybe the IETF should consider why Anne isn't doing it in the IETF.
>
> Indeed. Good question: Anne, is there are particular reason why you
> chose not to pursue this work as an I-D? Let's get that particular issue
> resolved.

(I don't think Anne is on any of the cc'ed mailing lists.)

I can't speak for Anne, but having experienced the IETF via the hybi work,
my own opinion is that the main reason I wouldn't work with the IETF is
that the community these days values consensus over technical value and
running code, and the culture in the IETF doesn't value the kind of
specification style that IMHO leads to better interop. For example, this
very thraed -- we're having to argue to convince people that defining
error handling is even a valuable thing to do. I have no interest in
attempting to get anything done in an environment where that's the level
at which the conversation starts.

Note that this isn't the only work recently that has gone from the IETF to
the WHATWG. For example, the MIME Sniffing specification, which was
originally in the HTML spec, was moved to the IETF by Adam Barth, who has
done other work in the IETF successfully (e.g. Cookies). But in the end,
Adam gave up on specifying MIME sniffing in the IETF and moved it out, and
now it's found a home at the WHATWG:

   http://mimesniff.spec.whatwg.org/

The character encodings registry at IETF/IANA has also recently been, to
some extent, suplanted by work at the WHATWG after failed attempts at
getting the specs and registries at the IETF/IANA into better shape:

   http://encoding.spec.whatwg.org/

I spoke to Anne briefly and he pointed me to:

   http://wiki.whatwg.org/wiki/IETF

...which gives a very brief synopsis of why he's given up on the IETF.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

12345