Quantcast

[url] Requests for Feedback (was Feedback from TPAC)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
88 messages Options
12345
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[url] Requests for Feedback (was Feedback from TPAC)

Sam Ruby-2
My understanding (see forwarded message below) was that the IETF and W3C
TAG were going to issue statements providing input to the evolution of
the URL Standard in mid-November.  As November is now drawing to a
close, can I get an update on the status of this?

Additionally, the effort to merge my parser work with the remainder of
the URL standard is now at a point where I would like to encourage wider
review -- either by individuals or by groups:

https://specs.webplatform.org/url/webspecs/develop/

I'd suggest that the first three sections (namely, 'Goals', 'URLs', and
'Authoring Requirements') would be of particular interest to the IETF
and TAG, but I welcome input on all sections.

My preferred method if input is GitHub pull requests:

https://github.com/webspecs/url/pulls

Alternate methods of input (including discourse itself) and other
related links can be found here:

http://discourse.specifiction.org/t/about-the-url-category/691

Finally, input on the following bug would be appreciated:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946

- Sam Ruby

-------- Forwarded Message --------
Subject: [url] Feedback from TPAC
Date: Fri, 31 Oct 2014 17:01:50 -0700
From: Sam Ruby <[hidden email]>
To: WhatWG <[hidden email]>

bcc: WebApps, IETF, TAG in the hopes that replies go to a single place.

- - -

I took the opportunity this week to meet with a number of parties
interested in the topic of URLs including not only a number of Working
Groups, AC and AB members, but also members of the TAG and members of
the IETF.

Some of the feedback related to the proposal I am working on[1].  Some
of the feedback related to mechanics (example: employing Travis to do
build checks, something that makes more sense on the master copy of a
given specification than on a hopefully temporary branch.  These are not
the topics of this email.

The remaining items are more general, and are the subject of this note.
  As is often the case, they are intertwined.  I'll simply jump into the
middle and work outwards from there.

---

The nature of the world is that there will continue to be people who
define more schemes.  A current example is
http://openjdk.java.net/jeps/220 (search for "New URI scheme for naming
stored modules, classes, and resources").  And people who are doing so
will have a tendency to look to the IETF.

Meanwhile, The IETF is actively working on a update:

https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04

They are meeting F2F in a little over a week[2].  URIs in general, and
this proposal in specific will be discussed, and for that reason now
would be a good time to provide feedback.  I've only quickly scanned it,
but it appears sane to me in that it basically says that new schemes
will not be viewed as relative schemes[3].

The obvious disconnect is that this is a registry for URI schemes, not
URLs.  It looks to me like making a few, small, surgical updates to the
URL Standard would stitch all this together.

1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.

2) Reference draft-ietf-appsawg-uri-scheme-reg in
https://url.spec.whatwg.org/#url-writing as the way to register schemes,
stating that the set of valid URI schemes is the set of valid URL schemes.

3) Explicitly state that canonical URLs (i.e., the output of the URL
parse step) not only round trip but also are valid URIs.  If there are
any RFC 3986 errata and/or willful violations necessary to make that a
true statement, so be it.

That's it.  The rest of the URL specification can stand as is.

What this means operationally is that there are two terms, URIs and
URLs.  URIs would be of a legacy, academic topic that may be of
relevance to some (primarily back-end server) applications.  URLs are
most people, and most applications, will be concerned with.  This
includes all the specifications which today reference IRIs (as an
example, RFC 4287, namely, Atom).

My sense was that all of the people I talked to were generally OK with
this, and that we would be likely to see statements from both the IETF
and the W3C TAG along these lines mid November-ish, most likely just
after IETF meeting 91.

More specifically, if something along these lines I describe above were
done, the IETF would be open to the idea of errata to RFC3987 and
updating specs to reference URLs.

- Sam Ruby

[1] http://intertwingly.net/projects/pegurl/url.html
[2] https://www.ietf.org/meeting/91/index.html
[3] https://url.spec.whatwg.org/#relative-scheme



Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [url] Requests for Feedback (was Feedback from TPAC)

Domenic Denicola-2
> I'd suggest that the first three sections (namely, 'Goals', 'URLs', and 'Authoring Requirements') would be of particular interest to the IETF and TAG, but I welcome input on all sections.

Great stuff. I gave it a quick review and filed bugs at https://github.com/webspecs/url/issues; I know that wasn't in your list of feedback mechanisms, but it was the "bugs" link at the top of the document, and I <3 GitHub issues.

Speaking for myself (not for the TAG), I strongly support the stated goals. Perhaps the TAG can discuss the goals on our upcoming telecom.

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Sam Ruby-2
On 11/30/2014 03:36 PM, Domenic Denicola wrote:
>> I'd suggest that the first three sections (namely, 'Goals', 'URLs',
>> and 'Authoring Requirements') would be of particular interest to
>> the IETF and TAG, but I welcome input on all sections.
>
> Great stuff. I gave it a quick review and filed bugs at
> https://github.com/webspecs/url/issues; I know that wasn't in your
> list of feedback mechanisms, but it was the "bugs" link at the top of
> the document, and I <3 GitHub issues.

I see them:

https://github.com/webspecs/url/issues

GitHub issues WFM.  I'll start working this list tomorrow.  Meanwhile,
keep them coming!

> Speaking for myself (not for the TAG), I strongly support the stated
> goals. Perhaps the TAG can discuss the goals on our upcoming
> telecom.

Cool.  If you need anything from me, let me know.

- Sam Ruby


Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Mark Nottingham-2
In reply to this post by Sam Ruby-2
Hi Sam,

> On 1 Dec 2014, at 3:30 am, Sam Ruby <[hidden email]> wrote:
>
> My understanding (see forwarded message below) was that the IETF and W3C TAG were going to issue statements providing input to the evolution of the URL Standard in mid-November.  As November is now drawing to a close, can I get an update on the status of this?

I've discussed this with Barry, the responsible AD, who has said he's going to hold the document until this and another (unrelated) situation become more clear (and perhaps beyond) -- see:
  http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13358.html

> Additionally, the effort to merge my parser work with the remainder of the URL standard is now at a point where I would like to encourage wider review -- either by individuals or by groups:
>
> https://specs.webplatform.org/url/webspecs/develop/
>
> I'd suggest that the first three sections (namely, 'Goals', 'URLs', and 'Authoring Requirements') would be of particular interest to the IETF and TAG, but I welcome input on all sections.
>
> My preferred method if input is GitHub pull requests:
>
> https://github.com/webspecs/url/pulls
>
> Alternate methods of input (including discourse itself) and other related links can be found here:
>
> http://discourse.specifiction.org/t/about-the-url-category/691
>
> Finally, input on the following bug would be appreciated:
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946

Like Domenic, I strongly support these goals; I've done it in person, but I also want to publicly thank you for grasping the nettle -- one that has stung many a person.

Cheers,


>
> - Sam Ruby
>
> -------- Forwarded Message --------
> Subject: [url] Feedback from TPAC
> Date: Fri, 31 Oct 2014 17:01:50 -0700
> From: Sam Ruby <[hidden email]>
> To: WhatWG <[hidden email]>
>
> bcc: WebApps, IETF, TAG in the hopes that replies go to a single place.
>
> - - -
>
> I took the opportunity this week to meet with a number of parties
> interested in the topic of URLs including not only a number of Working
> Groups, AC and AB members, but also members of the TAG and members of
> the IETF.
>
> Some of the feedback related to the proposal I am working on[1].  Some
> of the feedback related to mechanics (example: employing Travis to do
> build checks, something that makes more sense on the master copy of a
> given specification than on a hopefully temporary branch.  These are not
> the topics of this email.
>
> The remaining items are more general, and are the subject of this note.
> As is often the case, they are intertwined.  I'll simply jump into the
> middle and work outwards from there.
>
> ---
>
> The nature of the world is that there will continue to be people who
> define more schemes.  A current example is
> http://openjdk.java.net/jeps/220 (search for "New URI scheme for naming
> stored modules, classes, and resources").  And people who are doing so
> will have a tendency to look to the IETF.
>
> Meanwhile, The IETF is actively working on a update:
>
> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04
>
> They are meeting F2F in a little over a week[2].  URIs in general, and
> this proposal in specific will be discussed, and for that reason now
> would be a good time to provide feedback.  I've only quickly scanned it,
> but it appears sane to me in that it basically says that new schemes
> will not be viewed as relative schemes[3].
>
> The obvious disconnect is that this is a registry for URI schemes, not
> URLs.  It looks to me like making a few, small, surgical updates to the
> URL Standard would stitch all this together.
>
> 1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.
>
> 2) Reference draft-ietf-appsawg-uri-scheme-reg in
> https://url.spec.whatwg.org/#url-writing as the way to register schemes,
> stating that the set of valid URI schemes is the set of valid URL schemes.
>
> 3) Explicitly state that canonical URLs (i.e., the output of the URL
> parse step) not only round trip but also are valid URIs.  If there are
> any RFC 3986 errata and/or willful violations necessary to make that a
> true statement, so be it.
>
> That's it.  The rest of the URL specification can stand as is.
>
> What this means operationally is that there are two terms, URIs and
> URLs.  URIs would be of a legacy, academic topic that may be of
> relevance to some (primarily back-end server) applications.  URLs are
> most people, and most applications, will be concerned with.  This
> includes all the specifications which today reference IRIs (as an
> example, RFC 4287, namely, Atom).
>
> My sense was that all of the people I talked to were generally OK with
> this, and that we would be likely to see statements from both the IETF
> and the W3C TAG along these lines mid November-ish, most likely just
> after IETF meeting 91.
>
> More specifically, if something along these lines I describe above were
> done, the IETF would be open to the idea of errata to RFC3987 and
> updating specs to reference URLs.
>
> - Sam Ruby
>
> [1] http://intertwingly.net/projects/pegurl/url.html
> [2] https://www.ietf.org/meeting/91/index.html
> [3] https://url.spec.whatwg.org/#relative-scheme
>
>
>

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


Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Sam Ruby-2
Mark, thanks for the support, but I think that this is a matter that
needs a bit more clarity and wide review.

PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to
officially request that the IETF take a position on this subject.

- Sam Ruby

[1] http://www.w3.org/wiki/IetfW3cLiaison

On 12/02/2014 12:12 AM, Mark Nottingham wrote:

> Hi Sam,
>
>> On 1 Dec 2014, at 3:30 am, Sam Ruby <[hidden email]> wrote:
>>
>> My understanding (see forwarded message below) was that the IETF and W3C TAG were going to issue statements providing input to the evolution of the URL Standard in mid-November.  As November is now drawing to a close, can I get an update on the status of this?
>
> I've discussed this with Barry, the responsible AD, who has said he's going to hold the document until this and another (unrelated) situation become more clear (and perhaps beyond) -- see:
>    http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13358.html
>
>> Additionally, the effort to merge my parser work with the remainder of the URL standard is now at a point where I would like to encourage wider review -- either by individuals or by groups:
>>
>> https://specs.webplatform.org/url/webspecs/develop/
>>
>> I'd suggest that the first three sections (namely, 'Goals', 'URLs', and 'Authoring Requirements') would be of particular interest to the IETF and TAG, but I welcome input on all sections.
>>
>> My preferred method if input is GitHub pull requests:
>>
>> https://github.com/webspecs/url/pulls
>>
>> Alternate methods of input (including discourse itself) and other related links can be found here:
>>
>> http://discourse.specifiction.org/t/about-the-url-category/691
>>
>> Finally, input on the following bug would be appreciated:
>>
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946
>
> Like Domenic, I strongly support these goals; I've done it in person, but I also want to publicly thank you for grasping the nettle -- one that has stung many a person.
>
> Cheers,
>
>
>>
>> - Sam Ruby
>>
>> -------- Forwarded Message --------
>> Subject: [url] Feedback from TPAC
>> Date: Fri, 31 Oct 2014 17:01:50 -0700
>> From: Sam Ruby <[hidden email]>
>> To: WhatWG <[hidden email]>
>>
>> bcc: WebApps, IETF, TAG in the hopes that replies go to a single place.
>>
>> - - -
>>
>> I took the opportunity this week to meet with a number of parties
>> interested in the topic of URLs including not only a number of Working
>> Groups, AC and AB members, but also members of the TAG and members of
>> the IETF.
>>
>> Some of the feedback related to the proposal I am working on[1].  Some
>> of the feedback related to mechanics (example: employing Travis to do
>> build checks, something that makes more sense on the master copy of a
>> given specification than on a hopefully temporary branch.  These are not
>> the topics of this email.
>>
>> The remaining items are more general, and are the subject of this note.
>> As is often the case, they are intertwined.  I'll simply jump into the
>> middle and work outwards from there.
>>
>> ---
>>
>> The nature of the world is that there will continue to be people who
>> define more schemes.  A current example is
>> http://openjdk.java.net/jeps/220 (search for "New URI scheme for naming
>> stored modules, classes, and resources").  And people who are doing so
>> will have a tendency to look to the IETF.
>>
>> Meanwhile, The IETF is actively working on a update:
>>
>> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04
>>
>> They are meeting F2F in a little over a week[2].  URIs in general, and
>> this proposal in specific will be discussed, and for that reason now
>> would be a good time to provide feedback.  I've only quickly scanned it,
>> but it appears sane to me in that it basically says that new schemes
>> will not be viewed as relative schemes[3].
>>
>> The obvious disconnect is that this is a registry for URI schemes, not
>> URLs.  It looks to me like making a few, small, surgical updates to the
>> URL Standard would stitch all this together.
>>
>> 1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.
>>
>> 2) Reference draft-ietf-appsawg-uri-scheme-reg in
>> https://url.spec.whatwg.org/#url-writing as the way to register schemes,
>> stating that the set of valid URI schemes is the set of valid URL schemes.
>>
>> 3) Explicitly state that canonical URLs (i.e., the output of the URL
>> parse step) not only round trip but also are valid URIs.  If there are
>> any RFC 3986 errata and/or willful violations necessary to make that a
>> true statement, so be it.
>>
>> That's it.  The rest of the URL specification can stand as is.
>>
>> What this means operationally is that there are two terms, URIs and
>> URLs.  URIs would be of a legacy, academic topic that may be of
>> relevance to some (primarily back-end server) applications.  URLs are
>> most people, and most applications, will be concerned with.  This
>> includes all the specifications which today reference IRIs (as an
>> example, RFC 4287, namely, Atom).
>>
>> My sense was that all of the people I talked to were generally OK with
>> this, and that we would be likely to see statements from both the IETF
>> and the W3C TAG along these lines mid November-ish, most likely just
>> after IETF meeting 91.
>>
>> More specifically, if something along these lines I describe above were
>> done, the IETF would be open to the idea of errata to RFC3987 and
>> updating specs to reference URLs.
>>
>> - Sam Ruby
>>
>> [1] http://intertwingly.net/projects/pegurl/url.html
>> [2] https://www.ietf.org/meeting/91/index.html
>> [3] https://url.spec.whatwg.org/#relative-scheme
>>
>>
>>
>
> --
> Mark Nottingham   https://www.mnot.net/
>

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Ted Hardie-2
Hi Sam,

The thread below touches on a number of things; just for clarity, are you asking Philippe and Wendy to ask the IETF to take a position on "the future of URIs/URLs" or some more tightly scoped piece of the discussion to date?

regards,

Ted Hardie

On Fri, Dec 5, 2014 at 8:52 AM, Sam Ruby <[hidden email]> wrote:
Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review.

PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject.

- Sam Ruby

[1] http://www.w3.org/wiki/IetfW3cLiaison


On 12/02/2014 12:12 AM, Mark Nottingham wrote:
Hi Sam,

On 1 Dec 2014, at 3:30 am, Sam Ruby <[hidden email]> wrote:

My understanding (see forwarded message below) was that the IETF and W3C TAG were going to issue statements providing input to the evolution of the URL Standard in mid-November.  As November is now drawing to a close, can I get an update on the status of this?

I've discussed this with Barry, the responsible AD, who has said he's going to hold the document until this and another (unrelated) situation become more clear (and perhaps beyond) -- see:
   http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13358.html

Additionally, the effort to merge my parser work with the remainder of the URL standard is now at a point where I would like to encourage wider review -- either by individuals or by groups:

https://specs.webplatform.org/url/webspecs/develop/

I'd suggest that the first three sections (namely, 'Goals', 'URLs', and 'Authoring Requirements') would be of particular interest to the IETF and TAG, but I welcome input on all sections.

My preferred method if input is GitHub pull requests:

https://github.com/webspecs/url/pulls

Alternate methods of input (including discourse itself) and other related links can be found here:

http://discourse.specifiction.org/t/about-the-url-category/691

Finally, input on the following bug would be appreciated:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946

Like Domenic, I strongly support these goals; I've done it in person, but I also want to publicly thank you for grasping the nettle -- one that has stung many a person.

Cheers,



- Sam Ruby

-------- Forwarded Message --------
Subject: [url] Feedback from TPAC
Date: Fri, 31 Oct 2014 17:01:50 -0700
From: Sam Ruby <[hidden email]>
To: WhatWG <[hidden email]>

bcc: WebApps, IETF, TAG in the hopes that replies go to a single place.

- - -

I took the opportunity this week to meet with a number of parties
interested in the topic of URLs including not only a number of Working
Groups, AC and AB members, but also members of the TAG and members of
the IETF.

Some of the feedback related to the proposal I am working on[1].  Some
of the feedback related to mechanics (example: employing Travis to do
build checks, something that makes more sense on the master copy of a
given specification than on a hopefully temporary branch.  These are not
the topics of this email.

The remaining items are more general, and are the subject of this note.
As is often the case, they are intertwined.  I'll simply jump into the
middle and work outwards from there.

---

The nature of the world is that there will continue to be people who
define more schemes.  A current example is
http://openjdk.java.net/jeps/220 (search for "New URI scheme for naming
stored modules, classes, and resources").  And people who are doing so
will have a tendency to look to the IETF.

Meanwhile, The IETF is actively working on a update:

https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04

They are meeting F2F in a little over a week[2].  URIs in general, and
this proposal in specific will be discussed, and for that reason now
would be a good time to provide feedback.  I've only quickly scanned it,
but it appears sane to me in that it basically says that new schemes
will not be viewed as relative schemes[3].

The obvious disconnect is that this is a registry for URI schemes, not
URLs.  It looks to me like making a few, small, surgical updates to the
URL Standard would stitch all this together.

1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.

2) Reference draft-ietf-appsawg-uri-scheme-reg in
https://url.spec.whatwg.org/#url-writing as the way to register schemes,
stating that the set of valid URI schemes is the set of valid URL schemes.

3) Explicitly state that canonical URLs (i.e., the output of the URL
parse step) not only round trip but also are valid URIs.  If there are
any RFC 3986 errata and/or willful violations necessary to make that a
true statement, so be it.

That's it.  The rest of the URL specification can stand as is.

What this means operationally is that there are two terms, URIs and
URLs.  URIs would be of a legacy, academic topic that may be of
relevance to some (primarily back-end server) applications.  URLs are
most people, and most applications, will be concerned with.  This
includes all the specifications which today reference IRIs (as an
example, RFC 4287, namely, Atom).

My sense was that all of the people I talked to were generally OK with
this, and that we would be likely to see statements from both the IETF
and the W3C TAG along these lines mid November-ish, most likely just
after IETF meeting 91.

More specifically, if something along these lines I describe above were
done, the IETF would be open to the idea of errata to RFC3987 and
updating specs to reference URLs.

- Sam Ruby

[1] http://intertwingly.net/projects/pegurl/url.html
[2] https://www.ietf.org/meeting/91/index.html
[3] https://url.spec.whatwg.org/#relative-scheme




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



Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Roy T. Fielding-3
In reply to this post by Sam Ruby-2
On Dec 5, 2014, at 8:52 AM, Sam Ruby wrote:

> Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review.
>
> PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject.

In order for the IETF to take a position on the subject, it would
require an Internet draft stating the position and an appropriate
public review.  Even so, at best what you would get is a bunch of
opinions on what might be a reasonable way forward.

IMO, a solution would be to just remove the bits of the URL spec
that say it redefines RFC3986 (because it doesn't), name the spec to
something reasonable (like "URL Object and Processing References in HTML"),
and then complete the work you have started on making the parsing
algorithm for references more closely reflect deployed implementations.
I don't think the IETF protocols that depend on RFC3986 would have
any problem with such a document, and it would satisfy the needs of HTML.

However, it is still ridiculous to claim that URI != URL in Web parlance.
URL is and always has been the subset of URI that can be used as a locator,
which most people understand to be equivalent to the set of all URI once
they figure out how HTTP works.  Changing the existing term URL to fit the
definition of a reference is just plain confusing, even within the HTML
specifications.  I know because I tried to do that myself in the early
drafts of RFC1808.  If the goal is to produce quality specifications,
we should expect the terms to be used correctly.

.....Roy





Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Sam Ruby-2


On 12/05/2014 12:49 PM, Roy T. Fielding wrote:

> On Dec 5, 2014, at 8:52 AM, Sam Ruby wrote:
>
>> Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review.
>>
>> PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject.
>
> In order for the IETF to take a position on the subject, it would
> require an Internet draft stating the position and an appropriate
> public review.  Even so, at best what you would get is a bunch of
> opinions on what might be a reasonable way forward.
>
> IMO, a solution would be to just remove the bits of the URL spec
> that say it redefines RFC3986 (because it doesn't), name the spec to
> something reasonable (like "URL Object and Processing References in HTML"),
> and then complete the work you have started on making the parsing
> algorithm for references more closely reflect deployed implementations.
> I don't think the IETF protocols that depend on RFC3986 would have
> any problem with such a document, and it would satisfy the needs of HTML.

Examples of non-HTML implementations:

http://nodejs.org/api/url.html
https://github.com/smola/galimatias
http://servo.github.io/rust-url/url/index.html

> However, it is still ridiculous to claim that URI != URL in Web parlance.
> URL is and always has been the subset of URI that can be used as a locator,
> which most people understand to be equivalent to the set of all URI once
> they figure out how HTTP works.  Changing the existing term URL to fit the
> definition of a reference is just plain confusing, even within the HTML
> specifications.  I know because I tried to do that myself in the early
> drafts of RFC1808.  If the goal is to produce quality specifications,
> we should expect the terms to be used correctly.

Historical considerations aside, modern releases of Chrome, Firefox,
Internet Explorer, and Safari have an object/function named
"window.URL".  I'm not optimistic that this can be changed at this point.

> ....Roy

- Sam Ruby

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Sam Ruby-2
In reply to this post by Ted Hardie-2
On 12/05/2014 12:55 PM, Ted Hardie wrote:
> Hi Sam,
>
> The thread below touches on a number of things; just for clarity, are
> you asking Philippe and Wendy to ask the IETF to take a position on "the
> future of URIs/URLs" or some more tightly scoped piece of the discussion
> to date?

Ideally, I'd like to have feedback on the entirety of the following
document:

https://specs.webplatform.org/url/webspecs/develop/

At a minimum, I would like to know whether or not the IETF is OK with
the goals:

https://specs.webplatform.org/url/webspecs/develop/#goals

I fear/suspect that doing so will require the topic of the future of
URIs/URLs to be addressed along the way.

> regards,
>
> Ted Hardie

- Sam Ruby

> On Fri, Dec 5, 2014 at 8:52 AM, Sam Ruby <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Mark, thanks for the support, but I think that this is a matter that
>     needs a bit more clarity and wide review.
>
>     PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking
>     you to officially request that the IETF take a position on this subject.
>
>     - Sam Ruby
>
>     [1] http://www.w3.org/wiki/__IetfW3cLiaison
>     <http://www.w3.org/wiki/IetfW3cLiaison>
>
>
>     On 12/02/2014 12:12 AM, Mark Nottingham wrote:
>
>         Hi Sam,
>
>             On 1 Dec 2014, at 3:30 am, Sam Ruby <[hidden email]
>             <mailto:[hidden email]>> wrote:
>
>             My understanding (see forwarded message below) was that the
>             IETF and W3C TAG were going to issue statements providing
>             input to the evolution of the URL Standard in mid-November.
>             As November is now drawing to a close, can I get an update
>             on the status of this?
>
>
>         I've discussed this with Barry, the responsible AD, who has said
>         he's going to hold the document until this and another
>         (unrelated) situation become more clear (and perhaps beyond) -- see:
>         http://www.ietf.org/mail-__archive/web/apps-discuss/__current/msg13358.html
>         <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13358.html>
>
>             Additionally, the effort to merge my parser work with the
>             remainder of the URL standard is now at a point where I
>             would like to encourage wider review -- either by
>             individuals or by groups:
>
>             https://specs.webplatform.org/__url/webspecs/develop/
>             <https://specs.webplatform.org/url/webspecs/develop/>
>
>             I'd suggest that the first three sections (namely, 'Goals',
>             'URLs', and 'Authoring Requirements') would be of particular
>             interest to the IETF and TAG, but I welcome input on all
>             sections.
>
>             My preferred method if input is GitHub pull requests:
>
>             https://github.com/webspecs/__url/pulls
>             <https://github.com/webspecs/url/pulls>
>
>             Alternate methods of input (including discourse itself) and
>             other related links can be found here:
>
>             http://discourse.specifiction.__org/t/about-the-url-category/__691
>             <http://discourse.specifiction.org/t/about-the-url-category/691>
>
>             Finally, input on the following bug would be appreciated:
>
>             https://www.w3.org/Bugs/__Public/show_bug.cgi?id=25946
>             <https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946>
>
>
>         Like Domenic, I strongly support these goals; I've done it in
>         person, but I also want to publicly thank you for grasping the
>         nettle -- one that has stung many a person.
>
>         Cheers,
>
>
>
>             - Sam Ruby
>
>             -------- Forwarded Message --------
>             Subject: [url] Feedback from TPAC
>             Date: Fri, 31 Oct 2014 17:01:50 -0700
>             From: Sam Ruby <[hidden email]
>             <mailto:[hidden email]>>
>             To: WhatWG <[hidden email] <mailto:[hidden email]>>
>
>             bcc: WebApps, IETF, TAG in the hopes that replies go to a
>             single place.
>
>             - - -
>
>             I took the opportunity this week to meet with a number of
>             parties
>             interested in the topic of URLs including not only a number
>             of Working
>             Groups, AC and AB members, but also members of the TAG and
>             members of
>             the IETF.
>
>             Some of the feedback related to the proposal I am working
>             on[1].  Some
>             of the feedback related to mechanics (example: employing
>             Travis to do
>             build checks, something that makes more sense on the master
>             copy of a
>             given specification than on a hopefully temporary branch.
>             These are not
>             the topics of this email.
>
>             The remaining items are more general, and are the subject of
>             this note.
>             As is often the case, they are intertwined.  I'll simply
>             jump into the
>             middle and work outwards from there.
>
>             ---
>
>             The nature of the world is that there will continue to be
>             people who
>             define more schemes.  A current example is
>             http://openjdk.java.net/jeps/__220
>             <http://openjdk.java.net/jeps/220> (search for "New URI
>             scheme for naming
>             stored modules, classes, and resources").  And people who
>             are doing so
>             will have a tendency to look to the IETF.
>
>             Meanwhile, The IETF is actively working on a update:
>
>             https://tools.ietf.org/html/__draft-ietf-appsawg-uri-scheme-__reg-04
>             <https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04>
>
>             They are meeting F2F in a little over a week[2].  URIs in
>             general, and
>             this proposal in specific will be discussed, and for that
>             reason now
>             would be a good time to provide feedback.  I've only quickly
>             scanned it,
>             but it appears sane to me in that it basically says that new
>             schemes
>             will not be viewed as relative schemes[3].
>
>             The obvious disconnect is that this is a registry for URI
>             schemes, not
>             URLs.  It looks to me like making a few, small, surgical
>             updates to the
>             URL Standard would stitch all this together.
>
>             1) Change the URL Goals to only obsolete RFC 3987, not RFC
>             3986 too.
>
>             2) Reference draft-ietf-appsawg-uri-scheme-__reg in
>             https://url.spec.whatwg.org/#__url-writing
>             <https://url.spec.whatwg.org/#url-writing> as the way to
>             register schemes,
>             stating that the set of valid URI schemes is the set of
>             valid URL schemes.
>
>             3) Explicitly state that canonical URLs (i.e., the output of
>             the URL
>             parse step) not only round trip but also are valid URIs.  If
>             there are
>             any RFC 3986 errata and/or willful violations necessary to
>             make that a
>             true statement, so be it.
>
>             That's it.  The rest of the URL specification can stand as is.
>
>             What this means operationally is that there are two terms,
>             URIs and
>             URLs.  URIs would be of a legacy, academic topic that may be of
>             relevance to some (primarily back-end server) applications.
>             URLs are
>             most people, and most applications, will be concerned with.
>             This
>             includes all the specifications which today reference IRIs
>             (as an
>             example, RFC 4287, namely, Atom).
>
>             My sense was that all of the people I talked to were
>             generally OK with
>             this, and that we would be likely to see statements from
>             both the IETF
>             and the W3C TAG along these lines mid November-ish, most
>             likely just
>             after IETF meeting 91.
>
>             More specifically, if something along these lines I describe
>             above were
>             done, the IETF would be open to the idea of errata to
>             RFC3987 and
>             updating specs to reference URLs.
>
>             - Sam Ruby
>
>             [1] http://intertwingly.net/__projects/pegurl/url.html
>             <http://intertwingly.net/projects/pegurl/url.html>
>             [2] https://www.ietf.org/meeting/__91/index.html
>             <https://www.ietf.org/meeting/91/index.html>
>             [3] https://url.spec.whatwg.org/#__relative-scheme
>             <https://url.spec.whatwg.org/#relative-scheme>
>
>
>
>
>         --
>         Mark Nottingham https://www.mnot.net/
>
>
>

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Roy T. Fielding-3
In reply to this post by Sam Ruby-2
On Dec 5, 2014, at 10:53 AM, Sam Ruby wrote:

> On 12/05/2014 12:49 PM, Roy T. Fielding wrote:
>> On Dec 5, 2014, at 8:52 AM, Sam Ruby wrote:
>>
>>> Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review.
>>>
>>> PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject.
>>
>> In order for the IETF to take a position on the subject, it would
>> require an Internet draft stating the position and an appropriate
>> public review.  Even so, at best what you would get is a bunch of
>> opinions on what might be a reasonable way forward.
>>
>> IMO, a solution would be to just remove the bits of the URL spec
>> that say it redefines RFC3986 (because it doesn't), name the spec to
>> something reasonable (like "URL Object and Processing References in HTML"),
>> and then complete the work you have started on making the parsing
>> algorithm for references more closely reflect deployed implementations.
>> I don't think the IETF protocols that depend on RFC3986 would have
>> any problem with such a document, and it would satisfy the needs of HTML.
>
> Examples of non-HTML implementations:
>
> http://nodejs.org/api/url.html
> https://github.com/smola/galimatias
> http://servo.github.io/rust-url/url/index.html

Yes, and each of those referenced docs would be greatly improved by not
using the same term URL for five different things.  The fact that
they do such contortions right now is purely because they are trying
to reuse the same terms as the WHATWG spec, with spectacular confusion
as a result.

>> However, it is still ridiculous to claim that URI != URL in Web parlance.
>> URL is and always has been the subset of URI that can be used as a locator,
>> which most people understand to be equivalent to the set of all URI once
>> they figure out how HTTP works.  Changing the existing term URL to fit the
>> definition of a reference is just plain confusing, even within the HTML
>> specifications.  I know because I tried to do that myself in the early
>> drafts of RFC1808.  If the goal is to produce quality specifications,
>> we should expect the terms to be used correctly.
>
> Historical considerations aside, modern releases of Chrome, Firefox, Internet Explorer, and Safari have an object/function named "window.URL".  I'm not optimistic that this can be changed at this point.

What does that have to do with anything?  The DOM object name doesn't
define the entire space.  If it did, then every occurrence of a URL
within the DOM under a different object name would require a new standard
to define it.

I don't see any problem with continuing to use URL as the API name
for an object that contains a parsed reference and produces a URL string.
That should be distinguishable by context (e.g., code).  What I have
a problem with is the notion that both the input and the output of
those processes is a URL.  That is madness.  There is a reason why
the input is called href or src, not URL.

....Roy




Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Mark Nottingham-2
In reply to this post by Sam Ruby-2
Sam,

> On 6 Dec 2014, at 3:52 am, Sam Ruby <[hidden email]> wrote:
>
> Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review.
>
> PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject.

I’ll (of course) defer to Philippe and Wendy as to what they do, but generally we try to keep the communication informal when possible, to keep things productive.

The “official” path is for them to send a Liaison Statement. Such a device needs to be addressed to someone; since there isn’t a WG that is actively working on URIs in general, it’d need to go the Applications Area, the IETF as a whole, or perhaps the IAB.

If the statement is asking for approval for your plan, or for “official” feedback, as Roy says we’d need consensus, and that’s not something we can do in a week or two — especially concerning URIs, where we’ve failed to make meaningful progress for several years now.

If you want a “yes, we’re aware of it” response, I think you’ve already got it, but you’re more than welcome to ask for it in official form.

See also:
  http://www.ietf.org/proceedings/91/minutes/minutes-91-appsawg
(search for “W3C Update”, and note that this is a condensation of a ~10 minute discussion)

Cheers,

[ with IETF Liaison hat on ]


>
> - Sam Ruby
>
> [1] http://www.w3.org/wiki/IetfW3cLiaison
>
> On 12/02/2014 12:12 AM, Mark Nottingham wrote:
>> Hi Sam,
>>
>>> On 1 Dec 2014, at 3:30 am, Sam Ruby <[hidden email]> wrote:
>>>
>>> My understanding (see forwarded message below) was that the IETF and W3C TAG were going to issue statements providing input to the evolution of the URL Standard in mid-November.  As November is now drawing to a close, can I get an update on the status of this?
>>
>> I've discussed this with Barry, the responsible AD, who has said he's going to hold the document until this and another (unrelated) situation become more clear (and perhaps beyond) -- see:
>>   http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13358.html
>>
>>> Additionally, the effort to merge my parser work with the remainder of the URL standard is now at a point where I would like to encourage wider review -- either by individuals or by groups:
>>>
>>> https://specs.webplatform.org/url/webspecs/develop/
>>>
>>> I'd suggest that the first three sections (namely, 'Goals', 'URLs', and 'Authoring Requirements') would be of particular interest to the IETF and TAG, but I welcome input on all sections.
>>>
>>> My preferred method if input is GitHub pull requests:
>>>
>>> https://github.com/webspecs/url/pulls
>>>
>>> Alternate methods of input (including discourse itself) and other related links can be found here:
>>>
>>> http://discourse.specifiction.org/t/about-the-url-category/691
>>>
>>> Finally, input on the following bug would be appreciated:
>>>
>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946
>>
>> Like Domenic, I strongly support these goals; I've done it in person, but I also want to publicly thank you for grasping the nettle -- one that has stung many a person.
>>
>> Cheers,
>>
>>
>>>
>>> - Sam Ruby
>>>
>>> -------- Forwarded Message --------
>>> Subject: [url] Feedback from TPAC
>>> Date: Fri, 31 Oct 2014 17:01:50 -0700
>>> From: Sam Ruby <[hidden email]>
>>> To: WhatWG <[hidden email]>
>>>
>>> bcc: WebApps, IETF, TAG in the hopes that replies go to a single place.
>>>
>>> - - -
>>>
>>> I took the opportunity this week to meet with a number of parties
>>> interested in the topic of URLs including not only a number of Working
>>> Groups, AC and AB members, but also members of the TAG and members of
>>> the IETF.
>>>
>>> Some of the feedback related to the proposal I am working on[1].  Some
>>> of the feedback related to mechanics (example: employing Travis to do
>>> build checks, something that makes more sense on the master copy of a
>>> given specification than on a hopefully temporary branch.  These are not
>>> the topics of this email.
>>>
>>> The remaining items are more general, and are the subject of this note.
>>> As is often the case, they are intertwined.  I'll simply jump into the
>>> middle and work outwards from there.
>>>
>>> ---
>>>
>>> The nature of the world is that there will continue to be people who
>>> define more schemes.  A current example is
>>> http://openjdk.java.net/jeps/220 (search for "New URI scheme for naming
>>> stored modules, classes, and resources").  And people who are doing so
>>> will have a tendency to look to the IETF.
>>>
>>> Meanwhile, The IETF is actively working on a update:
>>>
>>> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04
>>>
>>> They are meeting F2F in a little over a week[2].  URIs in general, and
>>> this proposal in specific will be discussed, and for that reason now
>>> would be a good time to provide feedback.  I've only quickly scanned it,
>>> but it appears sane to me in that it basically says that new schemes
>>> will not be viewed as relative schemes[3].
>>>
>>> The obvious disconnect is that this is a registry for URI schemes, not
>>> URLs.  It looks to me like making a few, small, surgical updates to the
>>> URL Standard would stitch all this together.
>>>
>>> 1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.
>>>
>>> 2) Reference draft-ietf-appsawg-uri-scheme-reg in
>>> https://url.spec.whatwg.org/#url-writing as the way to register schemes,
>>> stating that the set of valid URI schemes is the set of valid URL schemes.
>>>
>>> 3) Explicitly state that canonical URLs (i.e., the output of the URL
>>> parse step) not only round trip but also are valid URIs.  If there are
>>> any RFC 3986 errata and/or willful violations necessary to make that a
>>> true statement, so be it.
>>>
>>> That's it.  The rest of the URL specification can stand as is.
>>>
>>> What this means operationally is that there are two terms, URIs and
>>> URLs.  URIs would be of a legacy, academic topic that may be of
>>> relevance to some (primarily back-end server) applications.  URLs are
>>> most people, and most applications, will be concerned with.  This
>>> includes all the specifications which today reference IRIs (as an
>>> example, RFC 4287, namely, Atom).
>>>
>>> My sense was that all of the people I talked to were generally OK with
>>> this, and that we would be likely to see statements from both the IETF
>>> and the W3C TAG along these lines mid November-ish, most likely just
>>> after IETF meeting 91.
>>>
>>> More specifically, if something along these lines I describe above were
>>> done, the IETF would be open to the idea of errata to RFC3987 and
>>> updating specs to reference URLs.
>>>
>>> - Sam Ruby
>>>
>>> [1] http://intertwingly.net/projects/pegurl/url.html
>>> [2] https://www.ietf.org/meeting/91/index.html
>>> [3] https://url.spec.whatwg.org/#relative-scheme
>>>
>>>
>>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>

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




Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Sam Ruby-2
In reply to this post by Roy T. Fielding-3


On 12/05/2014 02:48 PM, Roy T. Fielding wrote:

> On Dec 5, 2014, at 10:53 AM, Sam Ruby wrote:
>> On 12/05/2014 12:49 PM, Roy T. Fielding wrote:
>>> On Dec 5, 2014, at 8:52 AM, Sam Ruby wrote:
>>>
>>>> Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review.
>>>>
>>>> PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject.
>>>
>>> In order for the IETF to take a position on the subject, it would
>>> require an Internet draft stating the position and an appropriate
>>> public review.  Even so, at best what you would get is a bunch of
>>> opinions on what might be a reasonable way forward.
>>>
>>> IMO, a solution would be to just remove the bits of the URL spec
>>> that say it redefines RFC3986 (because it doesn't), name the spec to
>>> something reasonable (like "URL Object and Processing References in HTML"),
>>> and then complete the work you have started on making the parsing
>>> algorithm for references more closely reflect deployed implementations.
>>> I don't think the IETF protocols that depend on RFC3986 would have
>>> any problem with such a document, and it would satisfy the needs of HTML.
>>
>> Examples of non-HTML implementations:
>>
>> http://nodejs.org/api/url.html
>> https://github.com/smola/galimatias
>> http://servo.github.io/rust-url/url/index.html
>
> Yes, and each of those referenced docs would be greatly improved by not
> using the same term URL for five different things.  The fact that
> they do such contortions right now is purely because they are trying
> to reuse the same terms as the WHATWG spec, with spectacular confusion
> as a result.
>
>>> However, it is still ridiculous to claim that URI != URL in Web parlance.
>>> URL is and always has been the subset of URI that can be used as a locator,
>>> which most people understand to be equivalent to the set of all URI once
>>> they figure out how HTTP works.  Changing the existing term URL to fit the
>>> definition of a reference is just plain confusing, even within the HTML
>>> specifications.  I know because I tried to do that myself in the early
>>> drafts of RFC1808.  If the goal is to produce quality specifications,
>>> we should expect the terms to be used correctly.
>>
>> Historical considerations aside, modern releases of Chrome, Firefox, Internet Explorer, and Safari have an object/function named "window.URL".  I'm not optimistic that this can be changed at this point.
>
> What does that have to do with anything?  The DOM object name doesn't
> define the entire space.  If it did, then every occurrence of a URL
> within the DOM under a different object name would require a new standard
> to define it.
>
> I don't see any problem with continuing to use URL as the API name
> for an object that contains a parsed reference and produces a URL string.
> That should be distinguishable by context (e.g., code).  What I have
> a problem with is the notion that both the input and the output of
> those processes is a URL.  That is madness.  There is a reason why
> the input is called href or src, not URL.

I've opened https://www.w3.org/Bugs/Public/show_bug.cgi?id=27528 on this.

> ....Roy

- Sam Ruby

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Sam Ruby-2
In reply to this post by Mark Nottingham-2
On 12/05/2014 03:49 PM, Mark Nottingham wrote:

> Sam,
>
>> On 6 Dec 2014, at 3:52 am, Sam Ruby <[hidden email]> wrote:
>>
>> Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review.
>>
>> PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject.
>
> I’ll (of course) defer to Philippe and Wendy as to what they do, but generally we try to keep the communication informal when possible, to keep things productive.
>
> The “official” path is for them to send a Liaison Statement. Such a device needs to be addressed to someone; since there isn’t a WG that is actively working on URIs in general, it’d need to go the Applications Area, the IETF as a whole, or perhaps the IAB.
>
> If the statement is asking for approval for your plan, or for “official” feedback, as Roy says we’d need consensus, and that’s not something we can do in a week or two — especially concerning URIs, where we’ve failed to make meaningful progress for several years now.
>
> If you want a “yes, we’re aware of it” response, I think you’ve already got it, but you’re more than welcome to ask for it in official form.
>
> See also:
>    http://www.ietf.org/proceedings/91/minutes/minutes-91-appsawg
> (search for “W3C Update”, and note that this is a condensation of a ~10 minute discussion)

What I am trying to do is distinguish between:

1) I've read the draft, I approve of it, and therefore I have no comments.

2) I've not read the draft, and therefore I have no comments.

Despite the fact that there is no active WG within the IETF working on
this, I would have thought that this would be a topic of significant
interest to the broader IETF community.  This would tend to argue for #1
above, but I fear that the current state is #2.

> Cheers,
>
> [ with IETF Liaison hat on ]
>
>> - Sam Ruby
>>
>> [1] http://www.w3.org/wiki/IetfW3cLiaison
>>
>> On 12/02/2014 12:12 AM, Mark Nottingham wrote:
>>> Hi Sam,
>>>
>>>> On 1 Dec 2014, at 3:30 am, Sam Ruby <[hidden email]> wrote:
>>>>
>>>> My understanding (see forwarded message below) was that the IETF and W3C TAG were going to issue statements providing input to the evolution of the URL Standard in mid-November.  As November is now drawing to a close, can I get an update on the status of this?
>>>
>>> I've discussed this with Barry, the responsible AD, who has said he's going to hold the document until this and another (unrelated) situation become more clear (and perhaps beyond) -- see:
>>>    http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13358.html
>>>
>>>> Additionally, the effort to merge my parser work with the remainder of the URL standard is now at a point where I would like to encourage wider review -- either by individuals or by groups:
>>>>
>>>> https://specs.webplatform.org/url/webspecs/develop/
>>>>
>>>> I'd suggest that the first three sections (namely, 'Goals', 'URLs', and 'Authoring Requirements') would be of particular interest to the IETF and TAG, but I welcome input on all sections.
>>>>
>>>> My preferred method if input is GitHub pull requests:
>>>>
>>>> https://github.com/webspecs/url/pulls
>>>>
>>>> Alternate methods of input (including discourse itself) and other related links can be found here:
>>>>
>>>> http://discourse.specifiction.org/t/about-the-url-category/691
>>>>
>>>> Finally, input on the following bug would be appreciated:
>>>>
>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946
>>>
>>> Like Domenic, I strongly support these goals; I've done it in person, but I also want to publicly thank you for grasping the nettle -- one that has stung many a person.
>>>
>>> Cheers,
>>>
>>>
>>>>
>>>> - Sam Ruby
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: [url] Feedback from TPAC
>>>> Date: Fri, 31 Oct 2014 17:01:50 -0700
>>>> From: Sam Ruby <[hidden email]>
>>>> To: WhatWG <[hidden email]>
>>>>
>>>> bcc: WebApps, IETF, TAG in the hopes that replies go to a single place.
>>>>
>>>> - - -
>>>>
>>>> I took the opportunity this week to meet with a number of parties
>>>> interested in the topic of URLs including not only a number of Working
>>>> Groups, AC and AB members, but also members of the TAG and members of
>>>> the IETF.
>>>>
>>>> Some of the feedback related to the proposal I am working on[1].  Some
>>>> of the feedback related to mechanics (example: employing Travis to do
>>>> build checks, something that makes more sense on the master copy of a
>>>> given specification than on a hopefully temporary branch.  These are not
>>>> the topics of this email.
>>>>
>>>> The remaining items are more general, and are the subject of this note.
>>>> As is often the case, they are intertwined.  I'll simply jump into the
>>>> middle and work outwards from there.
>>>>
>>>> ---
>>>>
>>>> The nature of the world is that there will continue to be people who
>>>> define more schemes.  A current example is
>>>> http://openjdk.java.net/jeps/220 (search for "New URI scheme for naming
>>>> stored modules, classes, and resources").  And people who are doing so
>>>> will have a tendency to look to the IETF.
>>>>
>>>> Meanwhile, The IETF is actively working on a update:
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04
>>>>
>>>> They are meeting F2F in a little over a week[2].  URIs in general, and
>>>> this proposal in specific will be discussed, and for that reason now
>>>> would be a good time to provide feedback.  I've only quickly scanned it,
>>>> but it appears sane to me in that it basically says that new schemes
>>>> will not be viewed as relative schemes[3].
>>>>
>>>> The obvious disconnect is that this is a registry for URI schemes, not
>>>> URLs.  It looks to me like making a few, small, surgical updates to the
>>>> URL Standard would stitch all this together.
>>>>
>>>> 1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.
>>>>
>>>> 2) Reference draft-ietf-appsawg-uri-scheme-reg in
>>>> https://url.spec.whatwg.org/#url-writing as the way to register schemes,
>>>> stating that the set of valid URI schemes is the set of valid URL schemes.
>>>>
>>>> 3) Explicitly state that canonical URLs (i.e., the output of the URL
>>>> parse step) not only round trip but also are valid URIs.  If there are
>>>> any RFC 3986 errata and/or willful violations necessary to make that a
>>>> true statement, so be it.
>>>>
>>>> That's it.  The rest of the URL specification can stand as is.
>>>>
>>>> What this means operationally is that there are two terms, URIs and
>>>> URLs.  URIs would be of a legacy, academic topic that may be of
>>>> relevance to some (primarily back-end server) applications.  URLs are
>>>> most people, and most applications, will be concerned with.  This
>>>> includes all the specifications which today reference IRIs (as an
>>>> example, RFC 4287, namely, Atom).
>>>>
>>>> My sense was that all of the people I talked to were generally OK with
>>>> this, and that we would be likely to see statements from both the IETF
>>>> and the W3C TAG along these lines mid November-ish, most likely just
>>>> after IETF meeting 91.
>>>>
>>>> More specifically, if something along these lines I describe above were
>>>> done, the IETF would be open to the idea of errata to RFC3987 and
>>>> updating specs to reference URLs.
>>>>
>>>> - Sam Ruby
>>>>
>>>> [1] http://intertwingly.net/projects/pegurl/url.html
>>>> [2] https://www.ietf.org/meeting/91/index.html
>>>> [3] https://url.spec.whatwg.org/#relative-scheme
>>>>
>>>>
>>>>
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [url] Requests for Feedback (was Feedback from TPAC)

masinter
URL is one of a small number of topics where coordination between IETF (and use of IANA) and W3C and WHATWG would improve the situation, because specs overlap and say different things, there are gaps, or just differences in terminology, timing, authority.

URL syntax, equivalence, I18N. URN.
Encodings. Origin. Mime sniffing.  Multipart/form-data. DBOUND (same site).

The list isn't long. I think that's it, for "willful violations". HTTP and JSON seem to be OK.

URL is just the most immediate, because at least there's some IETF activity with which to coordinate.
I don't want to assign blame, but let's not start with "there is no problem".

On the naming issue: I think it would be easier to get the IETF to readopt "URL" than it would to get WHATWG to use "URI" and "IRI". Perhaps because the name really doesn't matter much as long as it's explained, what matters is reducing confusion by agreeing on the name. So I'm prepared to help write an explanation about how we came to have URL, URI, URN, IRI, URC and why we got together and agreed to ..... URL.  

We haven't gotten to be able to discuss whether unknownscheme://コーヒー should be encoded in punycode or %-hex ... where 3987 doesn't say for sure.

Having one answer for IETF and another for the Web is bad for interoperability--scoping things to HTML is a bad idea.

Larry
--
http://larry.masinter.net

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Bjoern Hoehrmann
In reply to this post by Sam Ruby-2
* Sam Ruby wrote:

>What I am trying to do is distinguish between:
>
>1) I've read the draft, I approve of it, and therefore I have no comments.
>
>2) I've not read the draft, and therefore I have no comments.
>
>Despite the fact that there is no active WG within the IETF working on
>this, I would have thought that this would be a topic of significant
>interest to the broader IETF community.  This would tend to argue for #1
>above, but I fear that the current state is #2.

If I wanted something from the IETF community, I would try to respect
their customs. You are welcome to make an IETF Contribution submitting
your ideas as an Internet-Draft, for instance. Your sarcasm also does
not help.

I for my part have read the draft, do not know what it would mean to
"approve of it", I do have comments, but I see no way to contribute
them. One problem is that I would apparently have to waive "all
copyright and related or neighbouring rights", or be singled out for
not doing so in your proposal, wich I find unusual and inappropriate.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Bjoern Hoehrmann
In reply to this post by Sam Ruby-2
* Sam Ruby wrote:
>At a minimum, I would like to know whether or not the IETF is OK with
>the goals:
>
>https://specs.webplatform.org/url/webspecs/develop/#goals

At the moment that section reads, through W3C's html2txt service,

  Goals
 
     The URL standard takes the following approach towards making
     URLs fully interoperable:
       * Align RFC 3986 and RFC 3987 with contemporary
         implementations and obsolete them in the process. (E.g.
         spaces, other "illegal" code points, query encoding,
         equality, canonicalization, are all concepts not entirely
         shared, or defined.) URL parsing needs to become as solid
         as HTML parsing. [34][RFC3986] [35][RFC3987]
       * Standardize on the term URL. URI and IRI are just
         confusing. In practice a single algorithm is used for both
         so keeping them distinct is not helping anyone. URL also
         easily wins the [36]search result popularity contest.
       * Supplanting [37]Origin of a URI [sic]. [38][RFC6454]
       * Define URL’s existing JavaScript API in full detail and
         add enhancements to make it easier to work with. Add a new
         [39]URL object as well for URL manipulation without usage
         of HTML elements. (Useful for JavaScript worker
         environments.)
 
     As the editors learn more about the subject matter the goals
     might increase in scope somewhat.

I do not understand what is meant by the parenthetical in the first
point, neither does the last sentence seem meaningful to me. The second
point seems tolerable. I have no idea what the third point means, and
find the unexplained use of `[sic]` inappropriate. With respect to the
fourth point, documenting web browser APIs is, in doubt, just writing
down facts; I do not see how "the IETF" might not be OK with someone
doing that.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Julian Reschke
On 2014-12-06 01:31, Bjoern Hoehrmann wrote:
> * Sam Ruby wrote:
>> At a minimum, I would like to know whether or not the IETF is OK with
>> the goals:
>>
>> https://specs.webplatform.org/url/webspecs/develop/#goals
>
> At the moment that section reads, through W3C's html2txt service,

Thanks Björn!

>    Goals
>
>       The URL standard takes the following approach towards making
>       URLs fully interoperable:
>         * Align RFC 3986 and RFC 3987 with contemporary
>           implementations and obsolete them in the process. (E.g.
>           spaces, other "illegal" code points, query encoding,
>           equality, canonicalization, are all concepts not entirely
>           shared, or defined.) URL parsing needs to become as solid
>           as HTML parsing. [34][RFC3986] [35][RFC3987]

I think obsoleting RFC 3986 is a non-goal; *until* it is demonstrated
that there's actually a problem with that spec (at which point bug
reports should be sent).

> ...


Best regards, Julian

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Graham Klyne-2
On 06/12/2014 08:10, Julian Reschke wrote:

> On 2014-12-06 01:31, Bjoern Hoehrmann wrote:
>>    Goals
>>
>>       The URL standard takes the following approach towards making
>>       URLs fully interoperable:
>>         * Align RFC 3986 and RFC 3987 with contemporary
>>           implementations and obsolete them in the process. (E.g.
>>           spaces, other "illegal" code points, query encoding,
>>           equality, canonicalization, are all concepts not entirely
>>           shared, or defined.) URL parsing needs to become as solid
>>           as HTML parsing. [34][RFC3986] [35][RFC3987]
>
> I think obsoleting RFC 3986 is a non-goal; *until* it is demonstrated that
> there's actually a problem with that spec (at which point bug reports should be
> sent).

+1

I've been using RFC3986 in my work (as developer) for many years now, and find
it for the most part to be clear and unambiguous for my needs.  I also liberally
add references to RFC 3986 to my code where I feel it helps explain what I'm
doing.  For me, there's no particular benefit in having a different spec that
also explains how to parse a string to a URL/URI, and I don't really want to
have to absorb and reference a different spec for describing what constitutes a
valid URI/URL string and how to resolve a relative reference to obtain such a
string.

(I'm OK with the idea that there is a spec for processing strings into valid
URI/URL structures, for use by HTML parsers and other applications that require
similar functionality.  I see that as the primary function of the new URL
specification.)

I have a concern (but I can't tell if it's actually a problem) that
re-addressing the notion of relative references, which the new URL spec appears
to do, will invalidate some of the assumptions in my code that are based on RFC
3986 (e.g. a relative reference being defined syntactically by the absence of a
scheme, and use of the mechanism defined in RFC 3986 for resolving relative
references to absolute.)

Finally, I think there are other reasonable ways of getting from an input string
to a valid URI/URL.  In my current work, I'm making extensive use of CURIEs
(http://www.w3.org/TR/curie/) in JSON, with the goal that these can be resolved
to proper URIs according to the context in which they are used.  So I have a
problem with there being just "one true way" of resolving an intended resource
reference to a URI/URL.

In summary, it would, for me, be useful to keep the definition of a URI/URL
separate from details of how to process URI/URL related artifacts.  I would see
this as a natural division of labour between RFC3986 and the new URL specification.

#g
--

PS: on the naming thing of URI vs URL:  I have found there are places when it is
useful to actually distinguish between URI and URL strings, even within a single
data structure.  The difference is based on context and intended use rather than
any intrinsic difference in the values.  Often, the URI and URL for a resource
may be the same string, but sometimes I find a need to have different values
(e.g. for identifier strings that I want to remain stable when a resource is
moved to a different location).


Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Martin J. Dürst
In reply to this post by Sam Ruby-2
On 2014/12/06 07:38, Sam Ruby wrote:
> On 12/05/2014 03:49 PM, Mark Nottingham wrote:

>> If you want a “yes, we’re aware of it” response, I think you’ve
>> already got it, but you’re more than welcome to ask for it in official
>> form.

> What I am trying to do is distinguish between:
>
> 1) I've read the draft, I approve of it, and therefore I have no comments.
>
> 2) I've not read the draft, and therefore I have no comments.

I think such statements are rather easy to make for individuals, but not
for IETF (nor for that matter for the W3C or even the WHATWG).

> Despite the fact that there is no active WG within the IETF working on
> this, I would have thought that this would be a topic of significant
> interest to the broader IETF community.

This is all true. The problem is that this interest is spread out very
very thinly. Summing up every splitter of interest will add up to
significant interest, but the people who are actually interested enough
to read the document and comment are few and far between.

Regards,   Martin.

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [url] Requests for Feedback (was Feedback from TPAC)

Sam Ruby-2
On 12/07/2014 11:18 PM, "Martin J. Dürst" wrote:

> On 2014/12/06 07:38, Sam Ruby wrote:
>> On 12/05/2014 03:49 PM, Mark Nottingham wrote:
>
>>> If you want a “yes, we’re aware of it” response, I think you’ve
>>> already got it, but you’re more than welcome to ask for it in official
>>> form.
>
>> What I am trying to do is distinguish between:
>>
>> 1) I've read the draft, I approve of it, and therefore I have no
>> comments.
>>
>> 2) I've not read the draft, and therefore I have no comments.
>
> I think such statements are rather easy to make for individuals, but not
> for IETF (nor for that matter for the W3C or even the WHATWG).
>
>> Despite the fact that there is no active WG within the IETF working on
>> this, I would have thought that this would be a topic of significant
>> interest to the broader IETF community.
>
> This is all true. The problem is that this interest is spread out very
> very thinly. Summing up every splitter of interest will add up to
> significant interest, but the people who are actually interested enough
> to read the document and comment are few and far between.

I've met in person with Area Directors.  I've asking for the W3C/IETF
liaisons to make this happen.  I've outlined the beginnings of a problem
statement.  I've been very publicly working on a specification.  I've
documented significant differences between implementations.

If there are people who want to help, I'm willing to work with them.

The one thing I am not intending to do is to stop.

> Regards,   Martin.

- Sam Ruby

12345
Loading...