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

Sam,

> On 19 Dec 2014, at 11:08 pm, Sam Ruby <rubys@intertwingly.net> wrote:
> 
> What frustrates me is that we met, in person, face to face.  You proposed some specific actions whereby the IETF (where you are a member) and the TAG (where you are a member) would either endorse or propose changes to what I proposed.  I took notes and published them promptly:
> 
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0000.html
> 
> I've seen no follow through on what you personally proposed.

I understand that you’re frustrated, but it’s not productive to focus that frustration on me. You say “your proposals,” yet there were others from the TAG and IETF there, and I don’t recall being the sole genesis of this plan — it was a collaborative discussion over lunch. Your notes certainly don’t reflect the interpretation you take above.

I know you’ve been working hard on this, and that some people have been unresponsive — i’ve been prodding them too (as you’ve seen in CC’d e-mails). I choose to interpret their unresponsiveness as a sign that a) they’re busy, and/or b) that they believe that they can’t materially add to the discussion. If I think they need to participate more actively, I politely prod them again.


>  I want to know what it takes to get an endorsement from Mark Nottingham.  Not a thanks that I've picked up this work, an actual endorsement of URL Living Standard and/or the URL W3C Working draft, as well as the stated direction.

“I strongly support these goals.”  - <http://www.w3.org/mid/D504FED5-8F28-4F4C-89B8-949AE9B5C6B5@mnot.net>.

How else can I help? You have endorsements from two TAG members (Domenic and I) already; we can try to get some more, or get a blog entry published (cc:ing Dan). A Finding seems like a heavyweight mechanism for this...


> In addition, let me now up the ante.
> 
> You mentioned a W3C recommendation.  I have personally updated the document which is on the W3C Rec track:
> 
> http://www.w3.org/TR/url/
> 
> I have kept a working draft up to date:
> 
> http://rawgit.com/w3ctag/url/develop/url.html
> 
> Please tell me what it will take for me to formally propose that a RFC3986bis be created.  If necessary, I'll volunteer to be the author.

I’m not sure why you’re insisting on “formally” — the most *effective* way would be to write down a delta from 3986 somewhere (Internet-Draft, Wiki, whatever), circulate that for comment, and then (presuming the result is encouraging) ask the Area Directors to hold a WG-forming BoF at the next opportunity. At that stage, you’d want to start working on a proposed charter.

If you want to make it formal, submit it as an Internet-Draft, and then make a request for the BoF to the ADs. 

Note that that’s the most likely path forward — there could be others (see previous discussion on IETF consensus).

If you write down the delta, I’m happy to help you understand the next steps.

As I’ve said repeatedly before, I do not think that getting IETF Consensus on the Problem Statement document helps you get there, and that if anything, a liaison statement would be a better conduit. If you want to initiate a Liaison Statement exchange, you’ll need to work through Philippe and Wendy; if OTOH, you want to pursue IETF Consensus, I think you need a response from the ADs as to what your next steps should be. Again, I’m not convinced that either is necessary; as previously communicated, I explained what you’re doing to the APPSAWG in IETF91, and there wasn’t any pushback from those present. 

Regards,

> 
> - Sam Ruby
> 
> On 12/18/2014 11:01 PM, Mark Nottingham wrote:
>> 
>>> On 19 Dec 2014, at 12:47 pm, Larry Masinter <masinter@adobe.com> wrote:
>>> 
>>> Mark, as you know, consensus is built one person at a time.
>> 
>> As much as any aphorism is true, I agree.
>> 
>>> Do you agree with this document's "Problem Statement",
>>> that it identifies an important problem. If not, why not?
>>> 
>>> If so, do you believe that the Proposed Solution is the
>>> best course forward to pursue, and likely to succeed?
>>> Do you think the problem unsolvable, or do you have
>>> ideas for better solutions.
>>> 
>>> You, Mark. And others on the list of course.
>> 
>> This list is not a forum for building IETF consensus. I've directly CC:ed the relevant ADs for their thoughts on <http://tools.ietf.org/html/draft-ruby-url-problem-00>; my thoughts as liaison below.
>> 
>> Sam asked what the appropriate channels were, and I tried to point him in the right direction.
>> 
>> I don't disagree with the document -- I just don't understand how trying to get IETF Consensus on it helps, or is worth the (considerable) effort involved in doing so, as opposed to getting a sense of the IESG in a liaison statement exchange, or more informally.
>> 
>> Furthermore, doing so begs the question regarding the other organisations listed -- e.g., do we need a W3C Recommendation to serve the same function in that organisation?
>> 
>> What would help me do my job as liaison is to understand you intention is. If you're looking to get the IETF to agree to a path forward via consensus, it is likely to be difficult and time-consuming (as I and others have outlined), since organisations tend not to like to sign blank cheques like that.
>> 
>> Specifically, Section 4 proposes the following activities relating to IETF documents:
>> 
>> """
>> Build a plan to update or obsolete [RFC3986], [RFC3987], [RFC5895], and [kerwin-file-scheme] to be consistent with [URL-LS] and [UTS-46].
>> ...
>> Reconcile how [appsawg-uri-scheme-reg] and [URL-LS] handle currently unknown schemes, update [appsawg-uri-scheme-reg] to state that registration applies to both URIs and URLs...
>> """
>> 
>> RFC3987 and 3987 are standards-track documents, and anything that updates or obsoletes them needs to go through the process. Publishing a consensus document saying we're going to come up with a plan to do so seems overly bureaucratic, and fraught with the possibility that people's expectations will still fail to be met despite that consensus (since consensus to plan doesn't mean that there's consensus on *a* plan).
>> 
>> If you want to start working on them, the best way to do so is to bring issues to people's attention, either on the URI list, or as errata. Once we have data, we can start to talk about what's necessary, and how to go about that (e.g., in a WG-forming BoF). Yes, that's messy and slow, but I don't see how getting this document to consensus first helps avoid that.
>> 
>> RFC5895 is Informational, on the Independent Stream. If you want to update it, I suggest you engage the authors (Pete and Paul).
>> 
>> kerwin-file-scheme is currently being considered for adoption by the APPSAWG. If you want to make changes, just go ahead and start that discussion there.
>> 
>> appsawg-uri-scheme-reg is an active document in the APPAWG, and being held for the outcome of whatever's happening in the W3C. If you want to make changes, just go ahead and start that discussion there.
>> 
>> Pete, Barry - anything else?
>> 
>> Regards,
>> 
>> 
>>> 
>>> Thanks,
>>> Larry
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Mark Nottingham [mailto:mnot@mnot.net]
>>>> Sent: Thursday, December 18, 2014 3:36 PM
>>>> To: Sam Ruby
>>>> Cc: public-ietf-w3c@w3.org; Wendy Seltzer; Philippe Le Hégaret
>>>> Subject: Re: [url] Requests for Feedback (was Feedback from TPAC)
>>>> 
>>>> Hey Sam,
>>>> 
>>>>> On 18 Dec 2014, at 10:34 pm, Sam Ruby <rubys@intertwingly.net> wrote:
>>>> [...]
>>>>> I'm still looking for advice on how to get this approved as Informational plus
>>>> IETF Consensus.
>>>> 
>>>> Did you see <http://www.w3.org/mid/EBA7F2BE-DCC7-4BD2-AEAC-
>>>> 92790C30A92D@mnot.net>? I think that contains the starting points you need;
>>>> if you need more information, glad to help. Again I urge you to coordinate with
>>>> Wendy and Philippe (CC:ed).
>>>> 
>>>> Cheers,
>>>> 
>>>> 
>>>> --
>>>> Mark Nottingham   https://www.mnot.net/
>>>> 
>>> 
>>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 

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

Received on Friday, 19 December 2014 19:46:11 UTC