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

On 12/19/2014 02:45 PM, Mark Nottingham wrote:
> 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 was sitting right next to you when you suggested that I could expect 
"statements from both the IETF and the W3C TAG along these lines mid 
November-ish, most likely just after IETF meeting 91."  As you were the 
one who suggested it, and are a member of the IETF Applications Area 
Directorate and a member of the W3C Technical Architecture Group (TAG), 
as well as the IETF Liaison to the W3C, and I am looking to you to 
follow through with this.

(aside: nice looking resume at <https://www.mnot.net/personal/resume.html>)

> 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...

What you have done: publicly supported me working in this general area, 
making others aware of this work, publicly thanking me for "grasping the 
nettle" (something I had to look up :-)) and labeling the work as an 
"aphorism" (OUCH!)

Now let me contrast what Paul Hoffman has done:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13504.html

In but a few words, he has actually made a recommendation.  That's what 
I'm looking for from the IETF and from the TAG.  And whether you like it 
or not, that involves you.

>> 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).

You know it is not that simple.

You've seen the input from a number of people.  People who haven't 
looked at the data that I have prepared, but are too willing to make the 
categorical assertion that RFC 3986 is not to be touched.

On this very mailing list, I got the request from two different 
individuals that a good first step would be to write a Problem 
Statement.  One offered to work with me, and I took him up on that offer.

> 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.

I hope you can see my frustration.

First, you suggest a liaison statement in October.  It doesn't happen in 
November.  I follow up with suggestions made here to create a Problem 
Statement, and now you say that's not going to help me get there.  Now 
you suggest a liaison statement again.

All I can say is:

Grrr.

- Sam Ruby

> 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 20:15:24 UTC