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

On 12/22/2014 04:16 AM, Mark Nottingham wrote:
>
>> On 22 Dec 2014, at 8:10 am, Sam Ruby <rubys@intertwingly.net>
>> wrote:
>>
>> Building a specification that obsoletes RFC 3986 as well as RFC
>> 3987 is lower risk and less work than updating RFC 3986 and/or RFC
>> 3987 and then updating the URL Living standard based on this work;
>> all in the hopes that parts of the results might be picked up at
>> some later point by the IETF.
>
> The plan was to publish the URL LS (in the W3C, perhaps) and then try
> to adjust 3986/7 as necessary afterwards. Both of the paths you
> outline above seem to be new ones.

That may indeed be your plan.  I've not seen it documented.  I don't 
believe it is viable.

The WHATWG plan to obsolete both RFC 3986 and RFC 3987 has been long 
documented.

A proposal to actually work together may, in fact, be new.  It may also 
not be viable.

> When you say “a specification that obsoletes 3986/7”, what
> specification do you envision doing so? I.e., IETF, W3C, WHATWG? You
> might say these distinctions aren’t important to you, but they are to
> some.

RFC 3986/7 are nearly 10 years old, and I have data that shows that they 
don't reflect reality.  The same data shows problems with the WHATWG LS.

I'm willing to work with anybody interested in updating any or all of 
them.  I would encourage those that feel these distinctions are 
important to review the data.

> You can certainly propose updates to 3986/7; that’s done by
> submitting an internet-draft as outlined earlier (either listing the
> proposed changes, or making them wholesale).

See below.

>> If there is no interest in collaboration, then I'll simply continue
>> on the WHATWG plan of record, possibly intercepting with the W3C
>> should the proposed workmode be adopted.
>
> That’s where I think we are. I wouldn’t characterise it as “no
> interest in collaboration,” but rather “a healthy amount of concern
> about the issues involved in cross-organisational collaboration,
> along with respect for the scars gained in trying to revise these
> specifications in the past.” If you propose concrete technical
> changes to the documents, they will be taken seriously. What we can’t
> do, however, is guarantee an outcome.

I've identified technical problems in detail.  See below.  I've seen 
little evidence that they have been taken seriously by those that seem 
solely interested in venue discussions.

> As Julian says, the work needs to be started by describing the
> technical problem(s) in detail. draft-ruby-url-problem in its current
> form is NOT that document. What I think we need is some combination
> of an issues list and a set of proposed changes.

Here is data in detail:

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

> If you were serious about “upping the ante,” and you can write it
> down in reasonable time, we can request a BoF to discuss the work in
> Dallas; if it takes longer, Prague or Yokohama.

As you said above, there are indeed people who are interested in where 
this work takes place.  I'm interested in working with people on the 
technical issues.  If that affects where I do the work, that's fine with 
me, as where the work is done isn't important to me.  In fact, I have 
stated on a number of occasions that I'm profoundly uninterested in 
discussions solely of venue and by that I mean without technical content.

>> What I'm looking for is technical feedback on the URL Living
>> Standard and/or work being started at the IETF
>
> The URL LS has been advertised to the relevant IETF crowds, and we’ll
> continue to remind them of the work.
>
> What does technical feedback on work being started at the IETF mean?
> To get technical feedback, I think you need to propose concrete
> changes to 3986/7, or at least point out the specific deficiencies.

IDNA is an example of specific deficiency.  There are multiple standards 
in this area.  They disagree.  They are parameterized.  Implementations 
are not interoperable.

If you like I can point to specific test results.

>>> This doesn’t mean that incorporating what the W3C does will be
>>> an easy task, nor will it be without risks. However, what I’ve
>>> heard from the relevant Area Directors is that this is the most
>>> viable way forward, and that’s what I’m trying to communicate to
>>> you.
>>
>> I'll simply make the observation unless there is some movement at
>> the IETF that the risks will only increase over time.
>>
>> This is NOT an ultimatum.  There isn't a a point at time where a
>> go/no-go decision needs to be made.  But given the lack of
>> demonstrable progress in the last 90 or so days, I would suggest
>> that there be a cause for concern.
>
> The nut here seems to be what “some movement at the IETF” means. You
> seem to want to get IETF Consensus on a Plan, and the feedback I’ve
> been giving you is that a) that’s hard, and b) it’s probably not
> worth your time.
>
> What we can do is:
>
> 1) If you like, get a Liaison Statement exchange that a) assures that
> proposals to change RFC3986 will be taken seriously, and b) show that
> there’s been some level of inter-organisational coordination here

Current status: I met in person in October with the liaisons and thought 
this was going to happen in November.  For whatever reason, it didn't 
happen.  Meanwhile, I've seen some progress on discussions as to how 
cooperation will work in the W3C.  I'm willing to continue those 
discussions.  I've not seen similar progress in the IETF.

> 2) Make a BoF request to discuss a more meaty document, if/when it
> appears.

Here are meaty documents:

https://url.spec.whatwg.org/
https://specs.webplatform.org/url/webspecs/develop/
http://www.w3.org/TR/2014/WD-url-1-20141209/

If there are people who are interested in technical discussions about 
how to update RFC 3986/7 or other RFCs, I'll join them wherever they 
want to have those discussions.

- Sam Ruby

Received on Monday, 22 December 2014 11:59:55 UTC