To:
Rick Wesson <wessorh@ar.com>
cc:
Edward Lewis <edlewis@arin.net>, "Hollenbeck, Scott" <shollenbeck@verisign.com>, "'Eric Brunner-Williams in Portland Maine'" <brunner@nic-naa.net>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Tue, 18 Feb 2003 16:09:06 -0500
In-Reply-To:
Your message of "Tue, 18 Feb 2003 09:45:12 PST." <Pine.LNX.4.33.0302180942220.664-100000@flash.ar.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Is it the co-chairs or is it us? Digression. From -47 through -49 I worked for Engage, a company that had some value proposition associated with http cookies, the results of this were contributions to draft-jaye-http-state-mgt-nn.txt, contributions to the W3C's P3P spec (in particular, the mechanism and semantic scope from -jaye- to cookies), and the Customer Profile Exchange (CPex) trade body standard for onward transport of customer profiles (wicked close to what EPP is all about, minus the ICANN psychoactive drugs), to cookie handling done in IE 5.5 et seq, and to draft-ietf-http-state-man-mec (rfc2965). So, I had a modest exposure to a particular problem domain, and had some reason to think that http's state management mechanism provided a mechanism for sophisticated 3rd-party involvement in the http client-server model, not entirely limited to Satan Worship, animal sacrifice, popups or banner ads. I mentioned at the Plenary in Pittsburg (-48) that the IESG's note on the subject (draft-iesg-http-cookies-nn.txt) was in need of some contribution from people with subject matter expertise. [People who's 9-5 was cookies, demographics, profiling, and of course, Devil Worship.] From the podium, Fred Baker was quick to agree that not all clue resided on his side of the table. Yeah Fred! The next day I went in search of the authors, both the Apps Area ADs (then). One blew me off, with attitude. The other informed me that he knew more than I did, and the majority (of some group) was on his side. This latter exchange happened with John Klensin as an onlooker, which is one reason why John and I are friends, though we disagree on the polarity of gravity. So, draft-iesg-http-cookies-nn.txt became bcp44 and rfc2964, without any further distractions to its authors. There is a quote from the back of Mike Padlipsky's "Elements" that is appropos: Just because you are Constitutionally entitled to a personal opinion doesn't mean you're constitutionally entitiled to a professional opinion. So, here we are, presumably possessed of at least enough clue to start a fire using only damp bits of XML, stopped dead in our tracks for about a half-year, by stuff that appears to be fairly aged roadkill. Is it (a) the co-chairs' fault (and I've issues there, which are neither here nor there), or is it (b) our fault? I'm inclined to (b). 2026, in particular section 6.5.4, provides an appeal procedure. If the working group fails to get either (a) adequate progress, or (b) grounds to advance an appeal under section 6.5.4 of 2026, then the working group is technically done, and has exhausted the process mechanisms it has consensus to exploit. The idea that the IESG can function like line-noise is sort of endearing. Eric