Re: respecting IETF customs?

On 12/06/2014 12:54 AM, Larry Masinter wrote:
> As a side note to the ongoing URL discussion:
>
>> If I wanted something from the IETF community, I would try to respect
>> their customs. You are welcome to make an IETF Contribution
>> submitting our ideas as an Internet-Draft, for instance. Your sarcasm also does
>> not help.
>
> I don't think the comments were sarcastic.
>
> He makes a reasonable request, and facilitating around 'customs'
> is the job of IETF-W3C liaison group.
>
> What customs, anyway?
>
> This happens often.

Thanks Larry!

I will say that if the IETF-W3C liaison group feels that submitting this 
content as an Internet-Draft makes sense, I will follow through on that. 
  After all, publishing this content on WebPlatform.org was a result of 
me following up on a suggestion[1].  If there are other serious 
suggestions, I WILL follow up on them.

Meanwhile, here is a more stable version of that content, presented in 
W3C Working Draft form:

http://www.w3.org/TR/2014/WD-url-1-20141209/

It doesn't have some of the things I'm working on in it yet, but after 
all, that's what "more stable" means.

In the the "Participate" section in the front of that W3C Working Draft 
you will find a list of alternate venues for feedback.  Here's another 
venue:

http://discourse.specifiction.org/c/url

If creating another mailing list or tracking system would help, lets 
make that happen.  Meanwhile, I will say that most of the activity is 
happening or finding its way back here:

https://www.w3.org/Bugs/Public/buglist.cgi?component=URL&resolution=---

An example where help would be very much appreciated: would it be 
possible for somebody who not only is familiar with RFC 3986 but also 
has a sense for what parts might be changeable and what parts can't 
change to review the following:

https://url.spec.whatwg.org/interop/urltest-results/

That page shows how a number of user agents (including browser and 
non-browsers) parse strings as a URLs/URIs.  Search that page for the 
word "addressable".  Addressable[2] is intended to be a highly RFC 
compliant implementation.  Modulo any bugs it may have, it should be 
fairly representative of what the combination of RFC 3986 and RFC 3987 
require.  If there are any differences, lets let the author of 
addressable Bob Aman know.

And while that is a broad request, here is a much more focused request, 
define some test cases which will define how relative references should 
be evaluated against a base with an unknown URLs/URIs scheme:

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

Sometimes reading prose in the various specifications is difficult, and 
what you might want to explore isn't covered by the existing test cases. 
  Here are more interactive ways to compare the browser you are 
currently using against the specification I previously pointed you to:

https://url.spec.whatwg.org/reference-implementation/liveview.html
https://url.spec.whatwg.org/reference-implementation/liveview2.html
https://url.spec.whatwg.org/reference-implementation/liveview3.html

I encourage you to try Larry's example[3]: unknownscheme://コーヒー.  I 
don't know of any spec that recommends punycoding paths, but what the 
URL spec I pointed to does specify matches IE but not Firefox or Chrome. 
  There is some room for determining what the correct behavior is here.

Julian[4] and Graham[5] seem interested in making this work consistent 
with RFC 3986.  That doesn't surprise me at all, in fact, that's exactly 
what I expected the IETF to recommend[6], possibly with some errata.  If 
there are people are interested in making that work, I'm interested in 
working with them.  I've pointed out some differences above, and I'm 
willing to to the research into how existing user agents behave, and I'm 
willing to discuss how we can converge onto a single definition.

After all "rough consensus and running code" is what we all want to 
achieve, right?

- Sam Ruby

[1] http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0177.html
[2] https://github.com/sporkmonger/addressable
[3] http://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0011.html
[4] http://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0015.html
[5] http://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0016.html
[6] 
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0000.html

Received on Saturday, 6 December 2014 12:18:24 UTC