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
On 2012-10-23 11:29, Anne van Kesteren wrote:
> On Tue, Oct 23, 2012 at 11:19 AM, Julian Reschke <[hidden email]> wrote:
>> On 2012-10-23 11:09, Anne van Kesteren wrote:
>>> http://www.googlefight.com/index.php?word1=url&word2=uri
>>
>> I was referring to "whatever you find in @href" as opposed to "what RFC 3986
>> says it is".
>
> Ah okay, well if you have relative URLs and absolute URLs, it makes
> sense to call them URLs together.

"whatever you find in a @href" is neither a relative URL nor an absolute
URL. I don't think it's helpful to insist on that.

>>> This was about demonstrating that STD 66 is not a suitable interface.
>>> (I thought you suggested that. If not, sorry, hopefully it helps
>>> someone else.)
>>
>> OK, so if browsers put /% on the wire *and* servers rely on that, that would
>> be an issue. However, I'm not convinced the latter is the case.
>
> I had not really expected otherwise.

Yes, because you haven't convinced me. Do you happen to have a test case?

I just tried

<html>
    <body>
       <p>
         <a href="/%">Test /%</a>
       </p>
       <p>
         <a href="%">Test %</a>
       </p>
       <p>
         <a href="?%">Test ?%</a>
       </p>
    </body>
</html>

and of these, IE doesn't treat the first two as links (it just doesn't
send any network request).

That's why I said I'd like to see a concrete list of issues (real and
perceived), so that we can test them across browsers and find out
whether they *need* to break the 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)

Anne van Kesteren-4
On Tue, Oct 23, 2012 at 12:29 PM, Julian Reschke <[hidden email]> wrote:
> "whatever you find in a @href" is neither a relative URL nor an absolute
> URL. I don't think it's helpful to insist on that.

Nobody is. I plan on defining relative URL/absolute URL only as what
is valid. The input to the parser can just be href's attribute value.
As far as developers are concerned, they are to put a relative
URL/absolute URL as the value of the href attribute, but indeed nobody
can prevent them from putting something else in there and as they have
in legacy pages we need to deal with that somehow.


> I just tried
>
> <html>
>    <body>
>       <p>
>         <a href="/%">Test /%</a>
>       </p>
>       <p>
>         <a href="%">Test %</a>
>       </p>
>       <p>
>         <a href="?%">Test ?%</a>
>       </p>
>    </body>
> </html>
>
> and of these, IE doesn't treat the first two as links (it just doesn't send
> any network request).

I wish had more easy access to IE to reverse engineer what it's doing.
Did you test <a>.pathname and such too? If it still sends ?% the point
that STD 66 is not workable still stands. (And again I just gave
examples here, to be exhaustive you need to test all prohibited code
points.) This also does not test the fragment case.


> That's why I said I'd like to see a concrete list of issues (real and
> perceived), so that we can test them across browsers and find out whether
> they *need* to break the spec.

I did not start out by looking at what is wrong with STD 66 but rather
with what browsers and to a lesser extent curl/wget etc. are doing.
Unfortunately I don't have a Windows license. So making such a list of
issues would take a rather large chunk of my time that given past
experience I'm not sure is worth it.


--
http://annevankesteren.nl/

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

On Oct 23, 2012, at 12:50 PM, Anne van Kesteren wrote:

> On Tue, Oct 23, 2012 at 12:29 PM, Julian Reschke <[hidden email]> wrote:
>> "whatever you find in a @href" is neither a relative URL nor an absolute
>> URL. I don't think it's helpful to insist on that.
>
> Nobody is. I plan on defining relative URL/absolute URL only as what
> is valid. The input to the parser can just be href's attribute value.
> As far as developers are concerned, they are to put a relative
> URL/absolute URL as the value of the href attribute,

What Julian is trying to get across is that the content of an @href is a *URI Reference*, not a URI.

You and Ian seem to acidentally or deliberately ignore that distinction. Hence it appears you 'insist' that the value of an @href would be a URI.

And Julian is right. Insisting to ignore that distinction is not helpful because, as Roy already pointed out, the whole discussion is a different one if you were talking about 'fixing parsing of URI references'.

Jan


> but indeed nobody
> can prevent them from putting something else in there and as they have
> in legacy pages we need to deal with that somehow.
>
>
>> I just tried
>>
>> <html>
>>   <body>
>>      <p>
>>        <a href="/%">Test /%</a>
>>      </p>
>>      <p>
>>        <a href="%">Test %</a>
>>      </p>
>>      <p>
>>        <a href="?%">Test ?%</a>
>>      </p>
>>   </body>
>> </html>
>>
>> and of these, IE doesn't treat the first two as links (it just doesn't send
>> any network request).
>
> I wish had more easy access to IE to reverse engineer what it's doing.
> Did you test <a>.pathname and such too? If it still sends ?% the point
> that STD 66 is not workable still stands. (And again I just gave
> examples here, to be exhaustive you need to test all prohibited code
> points.) This also does not test the fragment case.
>
>
>> That's why I said I'd like to see a concrete list of issues (real and
>> perceived), so that we can test them across browsers and find out whether
>> they *need* to break the spec.
>
> I did not start out by looking at what is wrong with STD 66 but rather
> with what browsers and to a lesser extent curl/wget etc. are doing.
> Unfortunately I don't have a Windows license. So making such a list of
> issues would take a rather large chunk of my time that given past
> experience I'm not sure is worth it.
>
>
> --
> http://annevankesteren.nl/
>


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
In reply to this post by Anne van Kesteren-4

On Oct 23, 2012, at 12:50 PM, Anne van Kesteren wrote:

> This also does not test the fragment case.

Fragments are not sent to the server.

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)

Jan Algermissen-3
In reply to this post by Anne van Kesteren-4
Anne,

On Oct 23, 2012, at 12:50 PM, Anne van Kesteren wrote:

> I did not start out by looking at what is wrong with STD 66 but rather
> with what browsers and to a lesser extent curl/wget etc. are doing.
> Unfortunately I don't have a Windows license. So making such a list of
> issues would take a rather large chunk of my time that given past
> experience I'm not sure is worth it.

I find that rather odd.

You insist there is some problem that requires changing one of the two core specifications of the Web. But you are not willing to invest time and a bit of money to help producing the problem data that several of the people having authored these specs would like to see to understand your perceived problem?

If the problem is indeed there, I think it would be very much worthy of your time to try to persuade these people that it exists. And from all I know, they usually listen very closely.

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)

Anne van Kesteren-4
In reply to this post by Jan Algermissen-3
On Tue, Oct 23, 2012 at 1:03 PM, Jan Algermissen
<[hidden email]> wrote:
> On Oct 23, 2012, at 12:50 PM, Anne van Kesteren wrote:
>> This also does not test the fragment case.
>
> Fragments are not sent to the server.

They are still important to consider if we want STD 66 to be the interface.

And yes, I know about URI and relative references. We call URI an
absolute URL and a relative reference a relative URL and together we
call them URLs. We can have this discussion in whatever terminology
you prefer though. The input to the parser is always going to be a
relative reference, just sometimes there's no base URI.

As for your last point. We have invested time and money in explaining
several problems starting over four years ago. Nothing happened. I
just explained how I came to the text in the URL Standard. I gave up
trying to work with STD 66 because the people working on that never
invested time in my problems with it and the data I had gathered
(mostly studying code in implementations and writing adhoc tests)
suggested it was not a suitable starting point.


--
http://annevankesteren.nl/

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

On Oct 23, 2012, at 1:25 PM, Anne van Kesteren wrote:

> On Tue, Oct 23, 2012 at 1:03 PM, Jan Algermissen
> <[hidden email]> wrote:
>> On Oct 23, 2012, at 12:50 PM, Anne van Kesteren wrote:
>>> This also does not test the fragment case.
>>
>> Fragments are not sent to the server.
>
> They are still important to consider if we want STD 66 to be the interface.
>
> And yes, I know about URI and relative references. We call URI an
> absolute URL and a relative reference a relative URL and together we
> call them URLs.

Who is 'we'?

I don't, and I think many others don't either. Maybe this is part of the disconnect?

Jan




> We can have this discussion in whatever terminology
> you prefer though. The input to the parser is always going to be a
> relative reference, just sometimes there's no base URI.
>
> As for your last point. We have invested time and money in explaining
> several problems starting over four years ago. Nothing happened. I
> just explained how I came to the text in the URL Standard. I gave up
> trying to work with STD 66 because the people working on that never
> invested time in my problems with it and the data I had gathered
> (mostly studying code in implementations and writing adhoc tests)
> suggested it was not a suitable starting point.
>
>
> --
> http://annevankesteren.nl/


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 Cowan-3
In reply to this post by Graham Klyne-4
Graham Klyne scripsit:

> On 22/10/2012 23:35, Ian Hickson wrote:
> >Consensus isn't a value I hold highly,
>
> !

Just call him Frank Sinatra.

--
John Cowan   [hidden email]    http://ccil.org/~cowan
I am he that buries his friends alive and drowns them and draws them
alive again from the water. I came from the end of a bag, but no bag
went over me.  I am the friend of bears and the guest of eagles. I am
Ringwinner and Luckwearer; and I am Barrel-rider.  --Bilbo to Smaug

Reply | Threaded
Open this post in threaded view
|

websockets in the IETF, was: [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-23 01:59, Ian Hickson wrote:
> ...
> Whether WebSockets is a good idea or not is besides the point. The point
> is that the hybi group was not a pleasant experience for me. If I were to
> be in a position to do Web Sockets again, I would decline the opportunity
> to do it through the IETF. Doing it through the IETF made the work take a
> year longer than it would have, made the protocol less secure (the WG
> removed a number of defense-in-depth features), and made the spec a mess
 > ...

And, as far as I can tell, fixed a security problem in the original
design (which caused some UA implementers to actually disable what they
were shipping at that time): <http://w2spconf.com/2011/papers/websocket.pdf>

> (it's a mishmash of different editing styles). Plus, the group _still_
> hasn't done multiplexing, which some of the vendors said was a prereq to
> implementation, something which, prior to the IETF getting involved, was
> only 3 to 6 months out on the roadmap.
> ...

Indeed, but then wasn't it you arguing *against* having it in the base
spec? (see
<http://www.ietf.org/mail-archive/web/hybi/current/msg00239.html>)


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)

Tim Bray-3
In reply to this post by Jan Algermissen-3
You guys are wasting time. 

Hixie & his posse have made it extremely clear that they consider the UR* specification broken, and that they consider that any time invested in addressing the problem at the IETF to be wasted because the IETF is broken too.

I suggest that it’s not a good use of this mailing list’s time to try to convince Ian’s tribe to stop what they’re doing.  I suspect it’s not a good use of WHATWG-member time to continue to explaining their feelings about the IETF.

 -T

On Tue, Oct 23, 2012 at 4:34 AM, Jan Algermissen <[hidden email]> wrote:

On Oct 23, 2012, at 1:25 PM, Anne van Kesteren wrote:

> On Tue, Oct 23, 2012 at 1:03 PM, Jan Algermissen
> <[hidden email]> wrote:
>> On Oct 23, 2012, at 12:50 PM, Anne van Kesteren wrote:
>>> This also does not test the fragment case.
>>
>> Fragments are not sent to the server.
>
> They are still important to consider if we want STD 66 to be the interface.
>
> And yes, I know about URI and relative references. We call URI an
> absolute URL and a relative reference a relative URL and together we
> call them URLs.

Who is 'we'?

I don't, and I think many others don't either. Maybe this is part of the disconnect?

Jan




> We can have this discussion in whatever terminology
> you prefer though. The input to the parser is always going to be a
> relative reference, just sometimes there's no base URI.
>
> As for your last point. We have invested time and money in explaining
> several problems starting over four years ago. Nothing happened. I
> just explained how I came to the text in the URL Standard. I gave up
> trying to work with STD 66 because the people working on that never
> invested time in my problems with it and the data I had gathered
> (mostly studying code in implementations and writing adhoc tests)
> suggested it was not a suitable starting point.
>
>
> --
> http://annevankesteren.nl/



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)

Ted Hardie-2
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, 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,

Handing things off to the IETF and saying "please go do this work" has
a very low success rate, because that's not how the IETF works.  The
IETF works by bringing together folks interested in solving a
particular problem and putting them in a larger context; that context
can help those working on a point solution see other aspects of their
problem space.  It also provides a set of processes which can be
useful for decision making when the trade-offs may involve different
folks' oxes being gored.

In this case, the concern is that defining what you are doing as a
revision of the URL standard outside the IETF will:

* lose that larger context
* use a process which has a bias toward browser viewpoints, which
raises concerns about trade-offs outside that space
* generate a fork, either directly or in the creation of two
communities which understand URL to be either a subset of URI in the
STD 66 sense or the "input string to web identifier" sense that Anne's
work uses.

It's tedious when people say "you should come here and do the work",
and I apologize that I'm about to say it.  But for work which
redefines IETF standards, the IETF is really the place to do it, and
preserving that context is important to making sure that the
communities of use retain a single standard.  I share your frustration
with the pace of work on related topics, but I urge you to put energy
into the process rather than simply appropriating the term.

If you choose not call what you're doing a "URL" but by some other
term ("fleen" is my favorite), then the issue does not arise; at most,
someone needs to later define how a fleen and URL relate, but that's
much less likely to cause confusion.

My two cents, as an individual as always,

Ted

Reply | Threaded
Open this post in threaded view
|

Re: websockets in the IETF, was: [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, Julian Reschke wrote:

> On 2012-10-23 01:59, Ian Hickson wrote:
> > ...
> > Whether WebSockets is a good idea or not is besides the point. The point
> > is that the hybi group was not a pleasant experience for me. If I were to
> > be in a position to do Web Sockets again, I would decline the opportunity
> > to do it through the IETF. Doing it through the IETF made the work take a
> > year longer than it would have, made the protocol less secure (the WG
> > removed a number of defense-in-depth features), and made the spec a mess
> > ...
>
> And, as far as I can tell, fixed a security problem in the original
> design (which caused some UA implementers to actually disable what they
> were shipping at that time):
> <http://w2spconf.com/2011/papers/websocket.pdf>

The security issue in question was already fixed in the draft by the time
that paper came out.


> > (it's a mishmash of different editing styles). Plus, the group _still_
> > hasn't done multiplexing, which some of the vendors said was a prereq
> > to implementation, something which, prior to the IETF getting
> > involved, was only 3 to 6 months out on the roadmap. ...
>
> Indeed, but then wasn't it you arguing *against* having it in the base
> spec? (see <http://www.ietf.org/mail-archive/web/hybi/current/msg00239.html>)

I was arguing against having it in the first version, which I had planned
for Q3 2009 IIRC, and was planning on defining it as an extension protocol
in early 2010 (I even had a strawman ready). The hybi group argued and
argued and argued and argued and then decided to not have it in the first
version, which they ended up doing in Q4 2011, and still haven't done the
extension. So yeah, I stand by my point above.

--
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: websockets in the IETF, was: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)

James M Snell

It should be quite clear to everyone that the horse is quite dead at this point. Any further beating is entirely unnecessary. So let's wrap it up with this: the whatwg's spec language around urls has the potential to cause confusion among implementers, so please consider reworking that language to avoid such confusion. Period, end of story.

On Oct 23, 2012 2:12 PM, "Ian Hickson" <[hidden email]> wrote:
On Tue, 23 Oct 2012, Julian Reschke wrote:
> On 2012-10-23 01:59, Ian Hickson wrote:
> > ...
> > Whether WebSockets is a good idea or not is besides the point. The point
> > is that the hybi group was not a pleasant experience for me. If I were to
> > be in a position to do Web Sockets again, I would decline the opportunity
> > to do it through the IETF. Doing it through the IETF made the work take a
> > year longer than it would have, made the protocol less secure (the WG
> > removed a number of defense-in-depth features), and made the spec a mess
> > ...
>
> And, as far as I can tell, fixed a security problem in the original
> design (which caused some UA implementers to actually disable what they
> were shipping at that time):
> <http://w2spconf.com/2011/papers/websocket.pdf>

The security issue in question was already fixed in the draft by the time
that paper came out.


> > (it's a mishmash of different editing styles). Plus, the group _still_
> > hasn't done multiplexing, which some of the vendors said was a prereq
> > to implementation, something which, prior to the IETF getting
> > involved, was only 3 to 6 months out on the roadmap. ...
>
> Indeed, but then wasn't it you arguing *against* having it in the base
> spec? (see <http://www.ietf.org/mail-archive/web/hybi/current/msg00239.html>)

I was arguing against having it in the first version, which I had planned
for Q3 2009 IIRC, and was planning on defining it as an extension protocol
in early 2010 (I even had a strawman ready). The hybi group argued and
argued and argued and argued and then decided to not have it in the first
version, which they ended up doing in Q4 2011, and still haven't done the
extension. So yeah, I stand by my point above.

--
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 Ted Hardie-2
On Tue, 23 Oct 2012, Ted Hardie wrote:

> On Mon, Oct 22, 2012 at 2:46 PM, Ian Hickson <[hidden email]> 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,
>
> Handing things off to the IETF and saying "please go do this work" has a
> very low success rate, because that's not how the IETF works.

Ok, but "we disagree with you, do it differently" is not how it works
either.


> The IETF works by bringing together folks interested in solving a
> particular problem and putting them in a larger context

The problem here is that the bulk of the people here don't seem interested
in solving this particular problem. In fact, many don't seem to even think
that there is a problem to solve.


> In this case, the concern is that defining what you are doing as a
> revision of the URL standard outside the IETF will:
>
> * lose that larger context

By which I presume you mean "you'll miss good feedback".

My experience with the Web Sockets work at the IETF is that we got way
better feedback (in terms of technical usefulness, relevance, and style)
when it was at the WHATWG than when it was at the IETF. All the good
feedback we got at the IETF was from people who were already participating
in the WHATWG.

So I'm not sure that this is a given.


> * use a process which has a bias toward browser viewpoints, which raises
> concerns about trade-offs outside that space

Working at the IETF results in the opposite concern, of course.

You're all welcome to participate in the WHATWG.


> * generate a fork, either directly or in the creation of two communities
> which understand URL to be either a subset of URI in the STD 66 sense or
> the "input string to web identifier" sense that Anne's work uses.

If Anne does a good job, then STD 66 can just be updated to contain Anne's
work, and then there's no fork to worry about. If Anne does a poor job,
then people will ignore it, and there's still no fork to worry about. The
only way there could be a problem is if Anne does a good job, so people
pay attention to it, but the IETF for political reasons refuses to
acknowledge it. That's up to the IETF.


> It's tedious when people say "you should come here and do the work", and
> I apologize that I'm about to say it.  But for work which redefines IETF
> standards, the IETF is really the place to do it, and preserving that
> context is important to making sure that the communities of use retain a
> single standard.  I share your frustration with the pace of work on
> related topics, but I urge you to put energy into the process rather
> than simply appropriating the term.

The problem is that we have lost hope that the IETF is somewhere where
this work could even take place. There's too much stop energy (just look
at this thread -- Tim just said we were all wasting our time and should
all shut up!).

But suppose we did try. Let's in fact try: Hi guys, we need to fix STD 66
because it doesn't define error handling. Also it seems to be about time
to merge IRIs and URIs together since implementing IRIs on top of URIs
leads to a confusing implementation experience. We can call the result
just "URLs" since that's what the majority of people call these things.
Anne has a proposal for how to do it:

   http://url.spec.whatwg.org/

Does anyone object to us updating STD 66 to using this once it's ready?
How do we go about it?


> If you choose not call what you're doing a "URL" but by some other
> term ("fleen" is my favorite), then the issue does not arise

Since the IETF doesn't call it a URL anyway, I don't see the problem with
terminology.

--
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: websockets in the IETF, was: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)

Peter Saint-Andre-2
In reply to this post by James M Snell
+1

On 10/23/12 2:32 PM, James M Snell wrote:
> It should be quite clear to everyone that the horse is quite dead at
> this point. Any further beating is entirely unnecessary. So let's wrap
> it up with this: the whatwg's spec language around urls has the
> potential to cause confusion among implementers, so please consider
> reworking that language to avoid such confusion. Period, end of story.


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
In reply to this post by Ian Hickson

On Oct 23, 2012, at 11:34 PM, Ian Hickson <[hidden email]> wrote:

>  Let's in fact try: Hi guys, we need to fix STD 66
> because it doesn't define error handling.

Help me, I am just not getting it:

Why do you insist on 'fixing STD 66'?

What is the reason you are not willing to reframe the problem to 'fixing how we get from the provided string -the input to the reference construction process- to a STD-66-valid result'?

To me this is really what you are aiming at and dropping the 'fix the URI spec' language would get everyone on board immediately in my perception.


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)

Ted Hardie-2
In reply to this post by Ian Hickson
On Tue, Oct 23, 2012 at 2:34 PM, Ian Hickson <[hidden email]> wrote:
>> If you choose not call what you're doing a "URL" but by some other
>> term ("fleen" is my favorite), then the issue does not arise
>
> Since the IETF doesn't call it a URL anyway, I don't see the problem with
> terminology.
>

Please see RFC 3986, Section 1.1.3, which says:

   "A URI can be further classified as a locator, a name, or both.  The
   term "Uniform Resource Locator" (URL) refers to the subset of URIs
   that, in addition to identifying a resource, provide a means of
   locating the resource by describing its primary access mechanism
   (e.g., its network "location").  The term "Uniform Resource Name"
   (URN) has been used historically to refer to both URIs under the
   "urn" scheme [RFC2141], which are required to remain globally unique
   and persistent even when the resource ceases to exist or becomes
   unavailable, and to any other URI with the properties of a name."

While the document does recommend the use of the more generic term
"URI" it defines URL clearly and in a way that is significantly
different from that used in Anne's document and which you have
described as the aim of your work.

Note also that Anne's document contains this text:

"Align RFC 3986 and RFC 3987 with contemporary implementations and
obsolete them in the process."

Unless you get buy-in from the community that produced RFC 3986 and
RFC 3987, the production of this document *will* result in a fork, and
that is damaging to the Internet.  I urge you to pick a different term
(several far more useful ones than fleen have been suggested) and
avoid this needless conflict.  The WhatWG choosing to redefine IETF
standards is not contributing to a better web; it's simply making it
less clear for those outside the small cabal of standards workers what
they should do when faced with a URL.  Un-marked context shifts are
likely, and likely to be bad.  Avoiding them by picking a new term is
both easy and appropriate.

My personal opinion, as always,

regards,

Ted Hardie

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 Jan Algermissen-3
On Tue, 23 Oct 2012, Jan Algermissen wrote:

> On Oct 23, 2012, at 11:34 PM, Ian Hickson <[hidden email]> wrote:
> >
> > Let's in fact try: Hi guys, we need to fix STD 66 because it doesn't
> > define error handling.
>
> Help me, I am just not getting it:
>
> Why do you insist on 'fixing STD 66'?
>
> What is the reason you are not willing to reframe the problem to 'fixing
> how we get from the provided string -the input to the reference
> construction process- to a STD-66-valid result'?

Because that's not a good way to write specs. Implementors shouldn't have
to read three separate specs to implement one algorithm. The definition
for Base64 isn't spread into tree separate RFCs. You don't put the HTML
parser in a different spec than the HTML elements.

A spec for this kind of thing should define the following:

 - The conformance requirements for authors so that they can use the
   technology in a manner that avoids likely pitfalls

 - A processing model for each relevant implementation conformance class
   (software) that defines how you take the input and use it

In the case of these string, that means, to a first approximation:

 - A definition of what the valid syntax of these strings is.

 - A definition of how you get from one of these strings, whether valid or
   not, to the information you need to process it, in particular, for
   e.g. strings that reference specific files:
    - the scheme (what protocol you're going to be using)
    - the hostname and port of the remote host
    - the path and query string to pass to that host
    - the fragment identifier

So there should just be one spec, not three (IRIs, URIs, and the error
handling).

--
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 Ted Hardie-2
On Tue, 23 Oct 2012, Ted Hardie wrote:
>
> Unless you get buy-in from the community that produced RFC 3986 and RFC
> 3987, the production of this document *will* result in a fork, and that
> is damaging to the Internet.

I'm trying to work with y'all to see how we can update these specs instead
of having to do it elsewhere.


> I urge you to pick a different term (several far more useful ones than
> fleen have been suggested) and avoid this needless conflict.

What term we use isn't going to have any effect on whether it harms the
Internet. If curl decides it should use WHATWGRLs or whatever and wget
decides it should use IRIs or whatever, and the specs aren't compatible,
then wget and curl won't interoperate.

Then again, they already don't interoperate -- that's the problem we're
trying to fix -- so maybe the fork won't harm the Internet any more than
STD 66 already is. Might even help matters, if curl and wget both decide
to follow the WHATWGRLs spec (or whatever), instead of STD 66, and as a
result start interoperating.

$ curl 'http://example.com/a b' # fetches "/a b" from example.com
$ wget 'http://example.com/a b' # fetches "/a%20b" from example.com

--
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
In reply to this post by Ian Hickson

On Oct 24, 2012, at 12:43 AM, Ian Hickson <[hidden email]> wrote:

> On Tue, 23 Oct 2012, Jan Algermissen wrote:
>> On Oct 23, 2012, at 11:34 PM, Ian Hickson <[hidden email]> wrote:
>>>
>>> Let's in fact try: Hi guys, we need to fix STD 66 because it doesn't
>>> define error handling.
>>
>> Help me, I am just not getting it:
>>
>> Why do you insist on 'fixing STD 66'?
>>
>> What is the reason you are not willing to reframe the problem to 'fixing
>> how we get from the provided string -the input to the reference
>> construction process- to a STD-66-valid result'?
>
> Because that's not a good way to write specs. Implementors shouldn't have
> to read three separate specs to implement one algorithm. The definition
> for Base64 isn't spread into tree separate RFCs. You don't put the HTML
> parser in a different spec than the HTML elements.
>
> A spec for this kind of thing should define the following:

Then, how about going from 'fixing STD 66' to

'augmenting STD 66 with how we get from the provided string -the input to the reference construction process- to a valid URI'?


(Personally, I do not see any problems with having one spec defining the valid output and one spec defining how to get from input to valid output. But that is a discussion that can be easily separated from the current one.)

What matters is that nothing of the existing URI spec *changes*.

Can you agree on that?

Jan


>
> - The conformance requirements for authors so that they can use the
>   technology in a manner that avoids likely pitfalls
>
> - A processing model for each relevant implementation conformance class
>   (software) that defines how you take the input and use it
>
> In the case of these string, that means, to a first approximation:
>
> - A definition of what the valid syntax of these strings is.
>
> - A definition of how you get from one of these strings, whether valid or
>   not, to the information you need to process it, in particular, for
>   e.g. strings that reference specific files:
>    - the scheme (what protocol you're going to be using)
>    - the hostname and port of the remote host
>    - the path and query string to pass to that host
>    - the fragment identifier
>
> So there should just be one spec, not three (IRIs, URIs, and the error
> handling).
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


12345