Tech Insider					     Technology and Trends

			      USENET Archives

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ames!ucbcad!zen!
From: R...@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Subject: Minutes of X11 3D Workshop, 18-19 Jun 1987
Message-ID: <870630090409.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 30-Jun-87 09:04:00 EDT
Article-I.D.: KILLINGT.870630090409.5.RWS
Posted: Tue Jun 30 09:04:00 1987
Date-Received: Thu, 2-Jul-87 00:55:46 EDT
Sender: c...@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 860

  X11 3D Workshop minutes, 18-19 June 1987, MIT.
  Tom Morrissey (HP) and Jim Michener (Apollo)

     Marcel Meth, AT&T Bell Labs
     Mark Hood, Applicon/Schlumeberger
     Tony Barkans, Applicon/Schlumeberger
     Dave Gorgen, Apollo Computer Inc.
     Jim Michener, Apollo Computer Inc.
     Jud Harward, Center for Remote Sensing, Boston University
     Hann-Bin Chuang, Astronomy Dept, Boston University
     Bernard Servolle, Bull-MTS
     David Bailey, CalComp
     Patricia Barstow, CalComp
     Jan Silverman, CalComp
     Jan Hardenbergh, Cognition, Inc.
     Steve Blank, Dana Computer
     Bruce Borden, Dana Computer
     Mark Patrick, Dana Computer
     Dana Marnell, Data General Corp
     Ying-Sheng Wen, Data General Corp
     Brian A. Axtell, Digital Equipment Corp
     Laurence Cable, Digital Equipment Corp
     Dave Carver, Digital Equipment Corp
     George Champine, MIT / Project Athena
     William Clifford, Digital Equipment Corp.
     Dick Coulter, Digital Equipment Corp
     Jeff Friedberg, Digital Equipment Corp.
     Branko J. Gerovac, Digital Equipment Corp.
     Elana Granston, Digital Equipment Corp.
     Harry Hersh, Digital Equipment Corp.
     Robert Holt, Digital Equipment Corp.
     Kathleen Langone, Digital Equipment Corp.
     Leszek Kotsch, Digital Equipment (Europe) S.A.R.L.
     John McConnell, Digital Equipment Corp
     Rico Piantoni, Digital Equipment Centre Technique Europe
     Randy Nickel, Digital Equipment Corp.
     Pete Nishimoto, DEC - VMS Workstations
     Randi J. Rost, Digital Equipment Corp.
     Jeffrey S. Saltz, Digital Equipment Corp
     Reinhild Schwarz, Digital Equipment Corp
     Shreyas B. Shah, EDS/GM
     Roy Wirthlin, EDS/GM
     Stefan Noll, FhG AGD
     Gregg Orangio, General Electric, Silicon Systems Tech Dept
     Tom Morrissey, Hewlett-Packard
     John Howard Palevich, Hewlett Packard Laboratories
     Jeff Stevenson, Hewlett Packard
     Greg Laib, IBM
     Mitch Kuninsky, Masscomp
     David Wolfendale, Masscomp
     Mike Bailey, Megatek Corporation
     Paul Dworkin, MIT / Media Lab
     Bob Scheifler, MIT / LCS
     Y. Obi and Y. Hongo (Japan), NEC Systems Lab
     Robert L. Gordon, Prime Computer,Inc.
     Salim Abi-Ezzi, RPI / CICG
     Dan Reece, SDRC
     Mark Callow, Silicon Graphics
     Nai-Ting Hsu, Silicon Graphics Inc.
     Allen Leinwand, Silicon Graphics Inc.
     Andy van Dam, Stellar Computer & Brown University
     David Laidlaw, Stellar Computer
     Jerry Evans, Sun Microsystems
     Lewis Knapp, Sun Microsystems
     Eileen McGinnis, Sun Microsystems
     David Rosenthal, Sun Microsystems
     Dennis Doughty, Symbolics, Inc.
     Bill York, Symbolics, Inc.
     John Dalrymple, Tektronix (Information Display Group)
     Dave Verhoeven, Tektronix
     Georges Grinstein, University of Lowell, Graphics Research Lab
     Zhong-Yu Zhou, University of Lowell, Graphics Research Lab
     Deyang Song, University of Lowell, Graphics Research Lab
     Greg Cockcroft, Univ. of Michigan, Center for Info. Tech. Integration
     Bertram Herzog, Univ. of Michigan, Center for Info. Tech. Integration
     Michael Foody, Visual Edge Software Ltd
     Larry Atwood, Visual Information Technologies

  9.30 Called to order by Branko Gerovac.

  Branko did some straw polls to characterize the group.  Lots of
  vendors, x-windows users and implementers, 3D graphics systems
  implementers, graphics and windowing standard folk.  Not many
  application developers/users.

  Some X history.  Emphasize omission of "policy" in X.

  Discussion of possible meeting logistics.

  Version 2.07 X3D was distributed prior to the meeting.  This proposal has
  been revised from comments from, and work with, Sun.  This new version is
  version 2.08, which will be presented at this meeting along with the deltas
  between version 2.07 and 2.08.

  What is the goal/focus of the meeting?
  Just to discuss the DEC/Sun (version 2.08 X3D) proposal?
  The only proposal received as input to the workshop is the 2.07/2.08
  X3D doc.  There was some discussion of whether we should talk about
  goals before we talk about a particular proposal.  One goal of the
  meeting is to solicit participation.

  Context / overview of effort  (Randy Nickel & Eileen McGinnis)

  What were they (DEC) trying to accomplish?
   1. to extend X for 3D graphics,
   2. to support graphics standards (especially PHIGS & PHIGS+ (the stable
      parts of PHIGS+)),
   3. to expose features and functionality that are provided in the newer
      technologies, and
   4. to do this in a timely manner, (requirements / need is there now for
      high performance 3D graphics within the X windowing environment).
      (before 1990)

  Questions from group:

    What is explicitly not be addressed by this?
      Imaging, CSG, 3D text are NOT explicitly addressed.
      Explicit support for PHIGS/PHIGS+ IS provided.

    Is a sample server to be provided?  Simple answer - yes.

    What is being proposed (protocol, library)?
      Just a protocol.  The library and C-binding in 2.07 were just examples.

  Technical overview "high order bits" (Randi Rost)

  Why is X3D necessary?
  - The X window system needs 3D graphics capabilities
  - PHIGS and PHIGS+ need an X window system binding
  - Current hardware products have more functionality than is
    exposed in graphics standards (not so true since PHIGS+ development
    has progressed)

  X3D Product Goals
  - Provide 3D graphics functionality as compatible X extension
  - Support efficient layered implementations of graphics standards products
  - Support workstation products from low end to high end
   - expose features of high end systems
   - allow efficient implementations on low end systems
  - Provide timely implementations on a variety of platforms

  X3D support for standards
  - PHIGS most important
  - Incorporate stable PHIGS+ functionality
  - Synchronize with October 87 PHIGS draft (DIS text)
  - Support other standards like GKS-3D

  Standardization goals and non-goals
  - create a standard 3D extension by working within the X community
  - no current plans to attempt ANSI/ISO standardization
  - must standardize X3D protocol to ensure network compatibility
  - may standardize X3D client library (X3lib)
   - X3lib provides thinnest layer on protocol
   - may not want to expose X3lib to standards users
   - vendors have existing libraries to support
  - don't need to standardize utilities
   - examples are included in proposal document
   - vendors may have own preferred conventions

  Primary features of X3D
  - X-compatible, extends X capabilities of 3D
   - full 3D graphics in window environment
   - network based
   - industry standard
   - hope for multi-vendor support
  - efficient PHIGS, GKS support
   - PHIGS, GKS developed before widespread use of window systems
  - based on modern graphics model
   - includes support  for reflection, lighting, antialiasing
   - flexible, efficient on a variety of systems
   - supports new hardware/software technology
  - Feasible, practical (actually a goal not a feature); can
     be implemented in a timely manner
   - X, X3lib prototype

  X3D (DEC) design team: (note: across many DEC groups)
     Randi Rost, DEC Workstation Systems Engineering
     Jeffrey Saltz, DEC Base Graphics Systems
     William Clifford, DEC Base Graphics Systems
     Peter Nishimoto, DEC VMS
     Jeffrey Friedberg, DEC High Performance Workstations
     Branko Gerovac, DEC High Performance Workstations
     Dick Coulter, DEC High Performance Workstations
     Brian Axtell, DEC Base Graphics Systems
     John McConnell, DEC Corporate Standards

  Technical details (Jeff Friedberg)

  X3D technical goals

    - promote illusion that each window is an independent 3D workstation
    - support structure mode and immediate mode with one interface
    - strive to keep interface "policy free" (no favors)
    - provide extensible, long-lived 3D interface
    - K.I.S.S. Keep It Simple Stupid (simplicity)

    ? Since there is this list of deferred things, is there a second order
    extension mechanism (for things like GDPs, GSEs, escapes)?
    Not yet, may be needed.

  X Client/Server model

       client    client
        \  \       /
         \  \     /
          v  v   v
           X server

    Connections are atomic-command oriented.

  X and X3D dispatchers (figure)

    Request -> Connection -> Core X  ----------------> X3D
               Queue         Dispatcher   Requests     Dispatcher
                             /  |  \                    /  |  \
                            v   v   v                  v   v   v
                            C o r e  X                   X 3 D

  Resources in X3D
    - GContexts (extended)
    - Windows (extended)
    - Pixmaps (extended)
    - Fonts (extended)
    - Font families (new)
    - Structures (new)
    - Format contexts (new) e.g. floating point
      Possibly not appropriate in graphics extensions, should possibly
      be in connection contexts in X

  Extended GContext
    - output primitives
    - transformation attributes
    - rendering attributes
    - raster attributes

  3D drawable hierarchy

           3D drawable
           /        \
     X drawable      \
       /       \      \
   window     pixmap   structure

  Output command processing (figure)

       output                output
       commands              commands
          |                     |
          v                     v
       Renderer              Element
          |                  Pointer
          |                     |
          v                     v
       Raster                Structure
        Data                  Elements
     .............           .........
     Window/Pixmap           Structure

  A renderer
    Purpose: distinguish (support) immediate mode and struct traversal

  Output commands         Traverser commands (Post Root, Set Regen Mode)
        |                             |
        v               yes           v
    ? call structure? ------> structure traverser <----> structures
        | no
       raster data

    A somewhat ambiguous and loaded model, hence some discussion ...
    ? Send same command to a struct AND to an X drawable? No
    ? What is the structure traverser really doing?
    ? What is in the server and what is in the client?
    Traverser and structures are in the server.
    ? What about synchronization of the traverser?
    Due to the contentious nature of the topic, this was referred to
    sub-group for discussion.
    ? Atomicity of commands? Intend to permit parallel traversals.
        There are two kinds of atomicity:
          Traversal atomic (cannot twiddle with environment during traversal)
          X command atomic (indivisible queue per connection)

  X3D rendering pipeline (figure)

   Base geometry & input colours
        |  local modelling coordinate system & input colours
     Colour type conversion
        |  local modelling coordinate system & base colours
     Composite modelling transformation
        |  world coordinate system & base colours
     View orientation transformation
        |  view reference coordinate system & base colours
     Light source shading computation
        |  view reference coordinate system & shaded colours
     Depth-cueing computation
        |  view reference coordinate system & depth-cued colours
     View mapping transformation
        |  normalized projection coordinate system & depth-cued colours
        |  clipped normalized projection coordinate system & clipped colours
     X window coordinate mapping
        |  X window coordinate system & clipped colours
     Device coordinate mapping
        |  physical device coordinate system & clipped colours
     Device colour mapping
        |  physical device coordinate system & physical device colours
   physical device coordinates & physical device colours

   ? write back atomicity?

  Renderer State
    - pipeline state
     - current attributes
     - GC aliases
     - light tables
     - colour table
     - filters containing name sets
     - hit test results
    - traverser state
     - root of posted structure network
     - implicit traversal mode

  A structure resource

   element pointer  ------->   structure elements

   editing mode

  Structure networks

            S1                        S4
            /\                        /\
           /  \                      /  \
          v    v                    v    v
         S2    S3                   S5   S6
                                     \   /
                                      \ /

  Call structure execution

  Structure A           _-> Structure B
    set text colour    /      polyline
    set HLHSR mode    /       set curve colour
    call structure B /        text
    set curve colour <---\__  set curve style
    set marker glyph        \-polyline

  11.05 break
  11.15 re-convene

  Overview of topics for further technical discussion
          (elaborated throughout meeting)
    - traversal semantics
    - client/server execution semantics
    - write back data to client
    - structure extensions (data per object)
    - double buffer proposal
    - input model
    - PHIGS[+] layering on top of X3D
    - peer interfaces
    - binary binding for protocol
    - conceptual CSS's "location" in X3D
    - how to GSE, GDP & escape
    - defaults

    - X11 protocol
    - X11 xlib
    - X11 xtoolkit
    - dpANS PHIGS
    - PHIGS+
    - X3D 2.08
    - X11 Input Extension proposal

  Possible proposals that may need to be considered
    - X3D 2.08
    - Something from Tektronix
    - Something from SGI
    - PHIGS+
    - Postscript 3D

  SGI view of things (Nai-Ting Hsu)
    A high-quality PHIGS implementation may not be the best path.
    SGI's experience with hundreds of significant real-time 3D applications.
      "Adequate" performance is not enough
      Experience shows a "RISG" approach wins
      Minimalism is the route to real-time 3D
    PHIGS on X3D delivers a "terminal" graphics model to applications
      The terminal model does not support dedicated 3D interaction well.
      The 3D graphics interface is a poor place to split an application.
      "RPC" (Remote Procedure Call) delivers a more general interface
    A simple graphics interface is called for
      Embodies a RISG approach, to support effective dynamic applications
      Relies upon powerful atomic primitives
      Delivers a flexible lighting model
      Provides interaction handling on the workstation
    SGI is working on a proposal and would like to distribute it around the
    Siggraph timeframe.  It is not being proposed to this group, since it
    is not strictly limited to X/windowing.  This is merely mentioned for
    the information of the group.  Contact SGI representatives (see attendees
    list) for more details and getting a copy of the proposal.

    ? More detail? Difference of emphasis. X3D 2.08 suggests how to
      partition things.
    ? Expect data structures to be on which side of 'wire'? Application
    ? Expect to take GL and RPC-ify it? Not necessarily
    ? Is there an extension language?
    ? Public Domain or licensed? Not decided yet.

  ? Postscript 3D was listed before as possible proposal.  Is anyone
      going to submit it for consideration?  (No response)

  A goals discussion:

     Library interface inappropriate, since it conflicts with
     PHIGS[+], GKS/GKS-3D, CGI.  No API (for now).

     Library interface (API) to the full power of the protocol is
     suggested to be necessary (e.g. for eventual testing).

     ? Goal to Add 3D to X or Do 3D in X window environment?
     (The latter implying having a local 3D application.)
     Several definitely in favor of the former.

     Protocol document not low enough; too much functional definition
     (heavily PHIGS[+] vs. CGI)

     Should this be a more general basis for a broader set of standards?
     Should the protocol support just PHIGS[+] and GKS/GKS-3D or should
     it support proprietary graphics interfaces and other graphics
     standards (CGI).

     Protocol extension versus window information access.

     Peer interface as implementation.

     Geometry & rendering (shape/sort) best done on server

     If goals is to support PHIGS[+], why not make the protocol map
     directly (1-1) to PHIGS[+] API?  The protocol is a different level
     in the system, and it is necessary to express the protocol in
     a form fitting into that level of the system and into X protocol.
      (But: It is hard to define something below the level of PHIGS that
      supports PHIGS.)

     Minimize network traffic.

     Metagoal: Have a simple set of goals.

     Suggestion: rename X3D 2.08 -> PHIGS[+] extension for X

     architectural issues (RPC ... underlying across)
       (this then is not an X extension)

    David Rosenthal's attempt at shooting down API advocates.
      - API already addressed by ISO/ANS
      - Server extension mechanism not defined yet, and won't perform
        well enough to meet graphics goals.  The server extension
        mechanism is not mature enough to use.
      - Therefore, only address protocol.

    Need for generic low-level (elemental) protocol, e.g.,
         "just" shaded triangles and vectors.

  12.45 broke for lunch

  14.00 reconvene

  How to proceed?
    Break into the following groups
      1. protocol specific to PHIGS (Gerovac)
      2. protocol for atomic generic low level
         (non-PHIGS, not anti-PHIGS) (Verhoven)
      3. peer interface for graphics (Palevich)
    to determine their respective goals.

  Broke into groups to at 14.15, to re-convene at 15.30

  Reconvene at 15.50

  Non-PHIGS protocol group.

    PHIGS is not the answer for everyone.
    Bruce Borden will prepare a proposal to interface at the Z-buffer
    level (a very low level) by August 1.

    Non-PHIGS goals
    - allow multiple extensions that don't interfere or preclude each other
    - have a low level 3D model
    - allow a decision to be made at runtime on how to partition the
      pipeline between the client and the server
    - allow for passing data by reference
    - provide access to various points in the pipeline
      How much 3D functionality can be added to X without violating the
      "no policy" goal?  Not much above "true colour pixels".

  Peer interface group.

    Goal - Allow peers to bypass X11 for the highest possible performance
    (w.r.t. output in windows).  This might be achieved by providing hooks
    for highest possible performance for environment where there is a
    "fast path" between the application and the hardware (but at the
    expense of portability).  The X11 server still arbitrates window
    clip lists and screen resources and distributed input, etc.

    One possible model

     3D clients         High performance clients       Pure X clients
       \    \              | \     | \                   /    /   /
        \    \             |  \    |  \                  |    |  |
        V     V            |   ----|----------------->   V    V  V
       3D server  ---------|-------|----------------->  X11 server
               \           |       |                    /
                \          V       V                   /
                 ------->  Hardware <------------------

    A possible model of a client (figure)

                    | Application |
                    |3D|   |      |
                    ----   | xlib |
                    |dd|   |      |
                    ----   --------
                     | |      |
          fast path >| \      | < X11 protocol
                     |  \     |
                     |   V?   V
                     |   --------------
                     |   | X11 server |
                     |   --------------
                     |        | dd x calls
                     V        V
                    |        dd         |

            Concern: clip list synchronization
                  local connection to (dd to X11 server) to get that

    What should be standardized?
       "express interest in fast-path"
       "this window's clip list should be synchronized"
      Sample server:
       "lock clip lists" machinery

    Fundamental requirements/issues:
      synchronizing hardware access (implementer problem)
      synchronizing cliplists between X11 server and clients

  PHIGS protocol extension group.

    - PHIGS protocol extension & encoding compatible with existing X
    - Incorporate stable PHIGS+ functionality
    - Synchronize with PHIGS DIS (Oct 87 draft)
    - Support a performance range of X server platforms
    - Timely definition of protocol extension
    - GKS-3D will be considered later either as addition to this
      extension OR as a separate extension

  Where do we go from here?  What did we learn from this?

  Query of folks' inclinations after seeing the goals of the efforts:
         (Multiple inclinations permitted)
     Most people are disposed toward working on PHIGS protocol.
     About 1/6 of the folks are interested in the non-PHIGS protocol.
     About 1/10 of the folks are interested in making a hybrid protocol

  Generic (non-PHIGS) protocol (Bruce Borden, Dana Computer)

                            |  + PHIGS+ protocol level
                     Database (display list)
                            |  * low-level generic protocol level
             Z-buffer <-> Draw
                       Frame buffer

    Problem: Where is lighting and shading? (All over, ugh.)

    Assertion: Bandwidth down to beyond the clip stage has the same
    bandwidth (37.5 megabytes/sec), then the bandwidth explodes, and
    hence is it useful at that level to define the protocol. (And
      possibly at higher levels, too.)

    Low level interface (at the level of "Z-buffer <-> draw" above)
      Drawing (all 3D)
        coloured vector
        coloured triangle
        random pixel write
        2D for all drawing primitives
        1D stipple for vectors
        map management

      (goal: Arbitrary previewing over the net, since
       REAL application dynamics would be impossible over net
       anyway -- see assertion above.)

  17.20 adjournment for the day.

  Friday, 19 June 1987.

  9.40 re-convene

  Process and logistics for further work.

    Umbrella X11-3D organization

      Report on X11 proposed future organization
        June 8 meeting of 10 entities
        MIT is going to prepare a proposal, available mid-July timeframe
        to create an industry consortium under the auspices of MIT as
        the organizer.  The goal being the continuation of work on X.
        Some fee for joining up.  Some commitment (say 3 years).  Members
        would sit on an advisory board.  MIT would be the decision making
        body.  The consortium would have a chief architect (an MIT person)
        who would make the decisions.  There would also be MIT staff to
        take care of the logistics of X maintenance/development.

        ? Would there need to be a sub-chief architect (also from MIT)
        for each major extension?  Don't know - all of this is still
        being formulated.
        ? Would the fee be graduated by company size?  Ditto.
        ? Would universities and/or government agencies be treated any
        different with respect to schedule?  Ditto.
        ? What is the deadline for having this in place?  Ditto.

        We, X3D extensions, would like to be sanctioned by this yet-
        to-be-formed group.  The disposition of the X community seems to be
        that if this group is reaching consensus, then continue.

    Timeliness, schedule

      What was/is the X11 schedule?
        before - lots of independent, background work, X6 to X10
        Apr 86 - first meeting
        Jul 86 - 1st public review draft
        Sep 86 - 1st public review closed
        Dec 86 - major Berkeley Un*x release with X10 toolkits (HP & DEC)
        Jan 87 - X users conference
        Feb 87 - alpha server release
        May 87 - alpha update
        Jun 87 - beta server release
        Sep 87 - close beta, release

      DEC intends to provide a sample server for X3D

      X11-3D proposed schedule
        19 Jun 87 - workshop, public review, output X-PHIGS 2.08
        22 Jul 87 - X-PHIGS 2.08 comments in
        26 Jul 87 - PHIGS+ public review begins
        03 Aug 87 - X3D meeting (west)
        17 Aug 87 - X-PHIGS 3.0 public review
        21 Sep 87 - X-PHIGS 3.0 public review ends - comments in
        21 Sep 87 - PHIGS+ comment period ends
        28 Sep 87 - X-PHIGS 3.05 document available
        01 Oct 87 - X3D meeting (east)
        05 Oct 87 - ASC X3H3 meetings (Lowell,MA)
        12 Oct 87 - X-PHIGS 3.1 available
                    protocol spec / function freeze
        19 Oct 87 - ISO PHIGS editting meeting (Fort Collins, CO - tentative)
        26 Oct 87 - PHIGS+ meeting (Troy,NY)
        09 Nov 87 - synchronize with PHIGS draft (DIS?/ANS? text)
        16 Nov 87 - X-PHIGS 4.0 draft available

    Sample server strategy
      When available?
      What available?
        Skeleton useful enough to be fleshed out?
        Possibly a assumes only a frame buffer?
        The first sample server would most likely be a full software server
        that would talk to a frame buffer.
        Possibly a subset sample server in April 1988.
      There will most likely not be a sample server in 1987.


      X11 process (fyi)
        - an architect / document editor, Bob Scheifler, spent 70% of his time
        - active individuals - contributors
        - active reviewers - less involved than contributors
        - daily exchange of mail with commenters
        - continual incremental exchange
        - periodic change summaries
        - periodic portions
        - occasional full releases
        - Bob drives people toward resolution
        - issues restatement when needed
        - mail log
        - geography not as important in the design process, but is
            important for sample server development

      ANS arena methodology
        - commenting period
        - meeting
         - discuss comments
         - draft & vote on issues
         - sometimes draft document changes
        - maintain issues log
        - publish draft document
          (sometimes after 1/2 cycle in committee)
        - (sometimes) written responses to commentors

     Which process is best for us?
       - X11 process better for the timeframe we are looking at
       - the architect is a pivotal individual in the X11 scheme
       - most folks like the electronic and incremental nature of
         X11 discussion mechanism
       - issues are a fundamental tool for progressing the effort
       - encourage comments in the form of issues / proposals
       - principal architect (or architect team) for each extension
         (right now, X-PHIGS+) needed
       - a chairman of the X graphics needed

      (see the schedule)

      Propose: initial architecture team comes from individuals who drafted
      2.08, other members welcome.  Architecture team dedicated (50-100%)
      to the effort.  DEC and Sun will contribute to this team.  The following
      organizations had representatives that felt that their organization
      should be on this team, but could not commit at this time: Tektronix,
      Data General, Apollo, HP, Prime, IBM, Bull.  Organizations should
      notify the chairman (Herzog, see below) of their level of commitment.

    Electronic mail distribution:

       The X11 3D graphics electronic mailing distribution list is accessed
       It is your responsibility to convert the domain name to mail paths
       familiar to you.
       To get on the list, send mail to:
       The x11-3d list will be zeroed out, so if you want to be on it, send in
       a request. will be set up this weekend as an interim
       Organizational local mailing lists are encouraged.  Each organization
       should set up organizational distribution lists, and only place one
       mail entry in the distribution list.


      It is just there as a placeholder until it can be turned over to MIT.
      DEC believes it is okay for organizations to duplicate the
      document.  If any organization has any problem copyrighting the
      document with the copyright on it, contact DEC for more copies
      or explicit release for the copyright.

    Chair nominations

      Roles & responsibilities of chair:
       - manage the decision making process
       - not chief architect
       - resource requirement?
       - public liaison (trade press, ANSI, professional societies)
       - MIT liaison
       - notification of activities (inside and outside group)
       - manage membership
       - Oversees all groups within X-graphics group, not just one
         group (e.g. PHIGS)
       - accessible (email)
       - convene and chair X-graphics meetings

        Bert Herzog, accepted and unanimously approved.
        email address:

    Double-buffering proposal is 'formally' with the X11 base group
        but comment and discussion in X3D arena is desired.

    Name of the top-level committee dealing with graphics for X.
    Ended up agreeing on X3D, but there was a strong sentiment for
    something more general, X-graphics.

    Much thanks to DEC and MIT/Athena for sponsoring the workshop.

    Meeting adjourned at 15.30.

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or

Electronic mail:			       WorldWideWeb: