Welcome to the 1st Joint PASC/TOG/WG15 Revision Group meeting. Andrew Josey called the meeting to order at 9.32am Wednesday September 2, 1998 at IBM's facility in Austin TX.

Andrew outlined the overall purpose of the meeting, giving some of the choices that we need to address. Decisions at this meeting would be made by concensus, we should identify what we can agree on, and what we cannot agree on.

Procedural issues are basically out of scope, though there may be some that we can deal with or at least identify at the meeting.

The main agenda item was to define the mission of this group and the scope of the deliverable for such a project.

Nick Stoughton agreed to act as secretary (reluctantly).

JZ stated that there are two audiences - system implementers and applications developers, and we must address both. There are also two obvious things that need to go into a revision, all the amendments and all the interpretations.

AR pointed out that we need to define the scope before we can go into any specifics. DC has a proposal for what should be in the scope. AUSTIN/1 and AUSTIN/2 were handed out. ACTION AJ to prepare web-site for common materials such as this and publicize it to the group.

There was substantial discussion on details of this, and in particular the diagram (AUSTIN/2). AUSTIN/2 proposes to leave out the Sample National Profile, Portability Considerations, Profiles, Performance Metrics, Realtime Files, and Proposals for Future Revision informative annexes. Portability Considerations should be added back in.

KS said that the informative annexes from .1/.2 containing the sample national profiles would be suitable to move into TR 14766.

FP pointed out that the diagram includes ISO-C with MSE, and we are not proposing to revise this standard. KS explained why we cannot revise this standard. AR stated that the problem was the coupling of versions. Two issues; how do we deal with overlap, and how do we deal with new things arising from the current ISOC-C (c9x) revision project. It is not all of ISO-C, but just the header files and APIs defined there. We extend them, in an upwardly compatible fashion (even though the ISO-C group have no historic record of reciprocating in this fashion!)

(coffee break 10.35-10.50)

SBB - why should XBD, XCU5 and XSH5 (in particular XBD) be the basis? DWC explained that this organization helped him to find things more easily. The alphabetic order was more useful than the topic order for him.

What parts of the Single UNIX Specification should be left out?

JZ asked about obsolescent functions - should they be withdrawn? They should be made optional. AR noted that there is a procedural issue here ? TOG puts things about options and what is and is not there is not part of the base standard, but a part of the brand. REFER TO PROCOMM.

This is a new book, we should get things right. Obsolescent functions (and legacy functions) should not be in the common standard; if anything, they should be in a separate book. Perhaps in an informative annex. Perhaps in a separate TOG spec. AGREED - no legacy or obsolescent code will be in the new standard (including stuff in POSIX marked as obsolescent).

Curses is not included.

SIDE DISCUSSION - what does "consensus" mean in this group? Curtis feels it means "unanimity", but no-one else agrees! We therefore have no consensus (by Curtis's definition) on the definition of consensus. We will attempt to document where there is any dissent from a general opinion.

Option handling: should we make more options? Or remove options? Combine options? Support for .13 needs to be included. AR proposed taking TOG feature groups, and possibly adding some for new amendments that are arriving. JZ explained the need to include .13 underlying areas of functionality. FP explained how .13 had achieved its goals in such a way as to decouple from the base standards. Products comply to .13, and not to .1. DWC said that this was not really legal unless we fix the base standard. SBB aren't we reluctant to add more options - we want to lose some, not gain some. PROPOSAL if either the SSWG or .13 WG make a proposal on exactly how to modify .1 and .2 by 12/31/99 this group would consider it. Problem: the WG no longer exists, their standard having been approved.

The scope should include an examination of which fine grain options should be forced on by an overriding option (leaving fine-grain options, but forcing them on). We need a list of those options that are used by current profiles (especially .13). AR suggested that all TOG options, except Legacy and Realtime Threads, are mandatory.

There are two levels in this discussion - what groups/options exist, and which should be made mandatory. SBB suggested that in the future we would be amending this revised standard, and how should options be handled as a basis for future amendments. The philosophy of amendments needs to be considered. NMS pointed out that we will not be amending this new standard, we would revise it. MB we need a namespace policy for options. DWC suggested that those amendments approved by 12/31/99 would initially be optional. CR disagreed. JZ explained that this must be the case - they are required to be new options in the way they are written.

LUNCH 12:02

JZ what about interpretations ? these need to be explicitly in the scope. We should have a goal of clearing the list completely - either fixed or agreed never to be fixed and therefore off the list.

KS notes that he has a concern regarding the overlap with ISO-C. Is there a way of organizing the NCS (new common spec) to solve the problem? It is felt useful to have everything in one place, and not to have to keep switching between NCS and C standards. This is an issue.

DWC pointed out that .2d (supercomputing batch extensions) is not included in SUS at present; should it be in scope? It is an approved amendment. Nobody knows of anyone who is using it. It could be withdrawn. ACTION: CR to check if it is used in the JTA. There is a freeware version of an implementation - Doug Gwyn at AIMES.

KS is a member of the ISO WG on i18n - should Locales be handed off to them? Should we pick up anything from them? AR and JZ believe this is premature at this point.

NMS proposed that wherever there is an "either - or" option we should try and choose one. AR thought this would probably disenfranchise too many. This digressed into a general discussion on duplicated but different functionality (e.g. XTI and sockets in XNS/1003.1g). What about where there is a POSIX version and a different SUS version (e.g. shared memory). AGREE to examine every either-or.

With respect to duplicated functionality, we probably need to leave these in. Streams and Sys V IPC are probably the hardest ones. These could be covered by options. This should get buy in from everyone.

Therefore, functional extensions from XSH/XCU not in POSIX.1/POSIX.2 should be added as an option, allowing it to be mandated for UNIX compliance. This will work fine for whole manual pages. Some discussion is needed on a case-by-case basis for extensions within a manual page.

The scope should not open the door for new utilities or APIs (e.g. gzip).

The revision should fix the stubs mess - this is covered by an existing PASC interpretation request.

[Break]

AJ: What Technical Requirements do we have, and what is the standing of this group - IEEE PAR? Fast-Track?

ACTION AJ to produce some formal strawman requirements for further discussion.

This is a meeting of participants of an IEEE Study Group, the TOG Base WG and a WG15 ad-hoc. Should we produce a PAR and become an IEEE WG? Should we use IEEE sync plan to get into ISO, or just fast-track. NMS proposed that we are a formal group under all three organizations in order to get as all three constituencies on board. PJ agreed that this would help the fully open process, but including people who did not intend to implement the result in the ballot group would be a bad thing. This looks like becoming a process issue, so no further discussion.

There will be one development group. Defer all other issues to PROCOMM.

We should produce a document that looks and feels like an IEEE PAR, since it asks all the right questions, including the PMC criteria and the ISO NP questions. Whether this then becomes an IEEE PAR will be answered later.

We will have all the TOG professional management and editorial backup.

JZ read out the PAR form questions. ACTION JZ to pass the filled in form to AJ to post on the web site.

We may need to do some additional work to get this through IEEE if we decide to go that way.

ACTION: AJ to produce a long version of the scope.

The PAR, criteria and ISO NP forms have been issued as AUSTIN/3, AUSTIN/4, and AUSTIN/5.

ACTION AJ to email these docs to the people who will be attending tomorrow's teleconference.

ACTION KS to prepare a liaison statement to ISO-C for our approval ahead of their October 1998 meeting.

[BREAK FOR EVENING ? 5.15 pm]

[RESUME THURSDAY ? 9.26 am]

Reviewing AUSTIN/4. Updated scope to include interpretations and resolutions from XNET/1003.1g IFF 1003.1g is approved in time. Add OGTGNET to the coordination.

Add PASC DSWG to coordination. Add PASC SUWG to the coordination (both by common membership).

[Teleconference set up at 10.00am, no-body on the line ?]

MICHAEL WILSON (Bull) joined at 10.09. Some concern about the interfaces that will be removed (legacy and obsolete). This was explained (in POSIX, there has been a warning for 10 yrs, for SUS the last two versions).

CHRIS HARDING joined at 10.12. Why is XNS dependent on 1003.1g? Because there is no POSIX equivalent. JZ: XNS and POSIX.1g are aligned, and if .1g fails to get through ballot, then the same ballot objections will exist againt the NCS. AJ: this does not mean that XNS cannot continue in its own right, and continue to be part of the UNIX branding program.

MW is also concerned about stability. AJ pointed out that we are working on some requirements that cover this.

CH asked about the procedural issues. PROCOMM will probably meet in San Diego during the PASC meeting.

[TELECONFERENCE ended 10.26 pm - BREAK, resume 10.54]

Continue looking at PAR and criteria. Revised versions of both documents derived.

KS How do we proceed at the ISO level; we have two projects at the ISO level, already approved. We are combining these two projects. There are several issues to address with ISO, particularly w.r.t. document format. We need to determine from ISO how numbering will work etc, and whether to form a New Project.

The same question is relevant to IEEE. It all depends on how many parts the resulting document will have. We will not have an answer to this until November.

[LUNCH 12.01 - 1.04]

Andrew presented AUSTIN/5. Discussion on Backward Compatibility; delete "Gratuitous" from this statement.

Maybe the word "requirements" is too strong ? AR has substantial problems with the "Extensibility", "Scalability", and "n-bit/architecture neutrality" sections. We should be constrained by the existing documents and functionality. AJ these are really guidelines. FM we need to say these things. AR we need to make sure the revision comes out in a timely fashion, if we have an open ended project, or open ended requirements, we will never finish. We have no control over the ballot process, but we do have control over the starting scope.

AJ: Only Backward Compatibility goes into the PAR. CR no, all of these should go in. AJ we need consensus on what goes in, not on what comes out.

LFS is a good example of what we want to fix for "Scalability". Make it possible for all applications to be large file aware. AR no, this is too open ended, and we won't get funding. JZ explained the problem with ISO-C not having an integral data type greater than 32 bits (e.g. dev_t needs to be integral). Although NCS may be n-bit clean, if ISO-C isn't then we are in trouble. There is some disagreement about whether ISO C does or does not allow an integral data type of 64 bits.

FM is not keen to produce any new standard if we can't even agree to come up with a method of interchanging data between vendors.

ACTION AJ to go away and examine scalability and come back with concrete proposals.

PJ said we need a clear statement of the problem.

ACTION AJ to compile a problem statement in conjunction with the proposals above for the scalability issue.

We have consensus on backward compatibility. We agree that the rest need further work, and AJ will do this.

AR would like the n-bit and architecture neutrality statements to gain consensus. No-one disagreed, so we must have consensus! Therefore AJ only needs to work on Extensibility and Scalability.

MB presented AUSTIN/6. The announcement/feature test macros can exist, but could have defined values (i.e. always on). This could break profiles (such as .13). ACTION MB to add columns for what .13, FIPS, & SUS requires to be able to control.

ACTION AJ to obtain a PDF version of .13 to add to the group reference CD.

MB does not feel that any of the realtime options need to be mandatory, but there should be a feature group that turns all 14 of them on. CR pointed out that there may be other options in the list by 12/31/99.

Only realtime threads are non-mandatory in SUS.

MB: The development option in XCU should be made mandatory. SCO would like to keep all of the development option optional.

[BREAK]

Audience; we have two basic audiences, application developers and system implementation. AR There are more people writing apps than there are implementing systems. People who implement systems are cleverer than people who write applications.

The ratio of application developers to system implementers is massive. Have things alphabetically, not subject oriented. Why is XNS not integrated? AR for business reasons. PJ this is not true.

NS what about organizing by feature groups? No, this is not needed.

KS the utilities are already sort of alphabetically sorted in POSIX.2. But not really - subject oriented Shell. Development. Other utilities.

JZ Some overriding things can go into a chapter heading if chapter oriented.

PJ let's must publish electronically, using HTML.

JZ ISO and IEEE want to make money by selling paper.

The final version must be one source, of something that will be rendered on paper. There may be other electronic guides to this material.

Rationale should be in a separate section (hyperlinked to its sources for html). Each section could be logically tagged to help in presenting it in alternative formats.

AGREED Alphabetic, based on SUSv2. Overarching requirements, covering several functions, go into common header file descriptions. Some overarching things might go into the introduction.

Language: "will" v "shall" etc. "I will die and no-one shall save me" v "I shall die and no-one will save me". AJ has a proposal from TOG on changing to something that is intended to be ISO aligned. AGREED that the NCS should be using ISO terminology.

One book of rationale, not three (or more).

Four books will result: XBD, XSH, XCU and XRAT. XNS will be rolled in to these, and not published as a separate volume, IFF 1003.1g is approved by 12/31/99. These are logical volumes. Keep .1 and.2 numbers. Add two new numbers for the new books. The rationale will be a Guide/TR. We will need to end up with four PARs, and at least NPs. These can be mechanically cloned from the one we produced yesterday.

Actively monitor the progress of PROCOMM, and decide when to hold the next meeting based on understanding the procedural issues ahead of us. Unlikely to meet before January. Probably 4 meetings during 1999 (one in Europe, rest US).