From Glen.Seeds@Cognos.COM Mon Jan 5 15:50:38 1998 Received: from sotr0081.cognos.com (gatekeeper.cognos.com [205.210.232.66]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id PAA07123 for ; Mon, 5 Jan 1998 15:50:23 +0100 Received: by sotr0081.cognos.com with Internet Mail Service (5.0.1458.49) id ; Mon, 5 Jan 1998 09:50:18 -0500 Message-ID: <650FF9D8BB62D111A48200805FE6469C0669A2@sotr0081.cognos.com> From: "Seeds, Glen" To: "'Roger Martin'" Cc: sc22wg15@dkuug.dk Subject: RE: (SC22WG15.1175) (wg15tag 1867) re: WG15 Ad hoc Meeting - Janu ary 11-12, 1998 Date: Mon, 5 Jan 1998 09:50:17 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" For what it's worth, this proposal makes me somewhat nervous. You seem to have done a reasonable job of specifying what's in the base standard and what isn't. Still, I find the prospect of future divergence as a result of a split disturbing, and all too probable. /glen > ---------- > From: Roger Martin[SMTP:rjmartin@eng.Sun.COM] > Sent: January 3, 1998 4:27 PM > To: Nick Stoughton > Cc: sc22wg15@dkuug.dk > Subject: (SC22WG15.1175) (wg15tag 1867) re: WG15 Ad hoc Meeting - > January 11-12, 1998 > > Hi, Nick. > > Happy New Year. > > I've excerpted comments from your message and am cc'ing this reply to > the WG15 reflector. > > So far you and David Blackwood are the only WG15 people I've heard > from. Lowell has a room set up for us (my suite), but I don't arrive > until about 11:00am, so we will probably need to meet in the lobby > at 1:00 and go to wherever the room is for the WG15 ad hoc meeting. > > >> > >> So, what do you, as TAG members, think of the proposal (see the > >> WG15 message which I just sent for the text of the proposed > >> resolution and some of the initial discussion)? > >> > >This proposal needs to be considered in conjunction with Petr's > >proposal from TOG. On its own, your proposal will kill all unfinished > >projects, since the cost of altering them to stand-alone (always > >assuming that it is technically feasible at all) will be prohibitive. > >I would therefore want at least to grand-father in many ongoing > >projects. I would also like to see methods developed to allow new > >standards to be built that do not break your "core" posix standards, > >but that do require, say, fundemental changes to fork and exec, or > >read and write, in the event that a given option is supported. > > > > I agree that Petr's proposal(s) are an integral part of this > discussion. > I have tried to take each separately, but in parallel, in order to > keep > the debate focussed, but it is all part of the central issue of how > do we keep POSIX standards viable in a rapidly changing standards > world > and marketplace. > > It's not clear that the cost of modifying the existing, unfinished > projects to be stand-alone would be "prohibitive". I have asked > several > people to investigate this and believe we need a serious assessment > of the burden the change would create. It is certainly something we > need some solid data on in reaching a decision on these proposals. > Hopefully we'll have some input by the time of the Ft. Lauderdale > meetings. > > I'd be less than candid if I didn't admit that there are some existing > projects that I do think should be killed. But that is not my > decision > to make, and that is not the central issue in the current debate > (although > the initial proposal did generate a very provocative discourse on the > future of the security work). > > I agree, two of the key challenges facing us are: 1) not breaking > existing POSIX standards, and 2) methods for making changes/extensions > which are needed. > > > > >In conjunction with the proposal to pack up PASC and go to TOG, it > >makes more sense. I believe that that is the more pressing question > >for us to agree on. > > > > Whether or not we move maintenance, and possibly some development, > of POSIX standards to TOG, there will still be a need for PASC/POSIX > activities for some time. > > First of all, there are many issues which must be resolved regarding > process, ability to participate, IPR, and fairness which must be > resolved before we could "pack up and go to TOG". If that is the > eventual course, I will support it. However, it is a difficult path > which we will have to take carefully and patiently. In the meantime, > PASC/POSIX will continue to be needed. > > Secondly, it is my opinion, that it is more likely that we will > compromise on a plan that moves the maintenance of the POSIX.1 and > POSIX.2 standards and test methods to TOG, but that some of the other > work will remain at PASC. In this case, it is imperative that we have > > clear agreement and definition of what constitutes that base set of > POSIX standards which will be the stable baseline for the industry. > I believe the draft resolution which I distributed defines that > baseline > and that it's passage is actually more important (initially) than the > proposals which will come from Petr's ad hoc. > > ....roger > > >