[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list