1. IP Statement.

2. Overview of working sessions of GGF8.

   - This session: Primer
   - Second: 60 Day comment and future work
   - Thursday: Overflow
   - Friday: Probably cancel.

3. Primer Discussion:

   - See attached slides.

3.1 Objectives of primer

   - Technology transfer, boot strap, What it is what it is and
     is not, Examples.

3.2 Primer team thanks (see slides)

3.3 Current Status

   - About 20% have downloaded it.
   - 68 pages.
   - Chapters 1 through 6 more advanced than.
   - 7 on, which need more input.
   - Help with Terminology and diagrams.
   - Oct 02: 9 pages, Jan 03: 22, Apr 03: 38, Jun 03: 68 (38 to review)
   - Sep 03: 100?

3.4 Outline:

3.5 Process:

   - Telecons Wed 16:00 UK time.
   - Target end to end review.
   - Drafts on the forge site.
   - Post comments via forge tracker.
 
3.6 Contribution:

   - Review and comments
   - Implementation examples (e.g. hardware services)
   - Actually work on a chapter.

3.7 Issues:

   - Interoperability, e.g. relationship to bindings.
   - Semantic interpretation, policy, examples
   - Resolver protocols.

   ? Is this feature creep?
      - Point out the scope of things outside OGSI rather than
        actually describe the approaches.
      - This is generally supported by

   ? The counter example seems to disappear later in the primer.

   ? Could it be implemented in GT3?
      - This is a single implementation and therefore outside scope.
      - Bias to one implementation.
      - Discussed on the list, and OGSI is not implementation specific.
      - It is not a GT3 primer.

   ? Do we need a compliance test?
      - This has been discussed in OGSI and GGF. It is quite complex
        and probably outside the scope of GGF.
      - If there are two implementations that your service works with,
        then it probably is ok.
      - A high level statement like the above might be good.
      - Point out the features of OGSI that support interoperability.
      
      ? Should there be a section relating the WS-I statement to OGSI? The
        discussion was not clear at this stage and the detailed seemed too
        complex. WS-I profiles should probably be referred to, but the
        detail would be difficult to fit in the primer.

      ? Should notions of identity should be discussed?
         - The primer should just say what the model is, but probably not
           specify how we arrived at that point.

      - Interoperability id the WS-I level problem. OGSI issues such as how
        to use service data might be an example. Push up the stack rather
        than down, i.e. from WSDL down.

     - Note: The new charter says we will do a resolver protocol.

     ? Do we need to split the primer into two parts? Information and
       implementation developer guide.
 
     - The developers guide is outside the scope of this WG.

     - Some examples of programmers guides do exits, reference to Tim.

     - The ongoing WSDL discussion should not influence the primer.

     ? What questions do you need answered?

     - Parts of the primer might be too deep.

     - We might need a section defining the audience.

     - Application developers probably need to know some things about the
       OGSI level, e.g. instance sameness, but not the details of the
       platform they are using.

     - Key differences to WSs:
         - SD allow you to publish attributes.
         - Lifecycle management grid enables WS.
         - Change management through inheritance
         - Service Group provides discovery.

     - OGSI is too silent on security. WS security is a partial answer only.
       Relationship to XML secure conversation. A section looking at
       definitions of terms in the security section and an outline of
       the possible security issues might be of interest to the community.

    - There was a roadmap question, but it seem to be more appropriate
      for OGSA-WG.

    ? Can OGSI be stateless web service? The key point is that WS do not
      conflict with OGSI, and some OGSI features (handles) can be used by
      WS that would otherwise be considered stateless.

        - Add sections describing how a WS could be improved with GS
          that are not based on state.

     - There was a discussion about the distinction between "Stateless" web
       service dogma and the reality of what is actually implemented behind
       the scenes (e.g. there is ALWAYS state.) Topic for OGSI's Thursday's
       session.

     - The state question is under general discussion in the wider
       community, but we were involved at a very early stage.

     ? How do we do multiple extensibility arguments to an extensible
       arguments? From Steve T's email:

> ...  We had substantial debates on
> this issue, and decided not to deal with this in OGSI v1.0.  The problem is
> that this is a slippery slope.  In the general case, you might want to
> describe multiple input parameters, and associated multiple associated output
> parameters, faults, an other properties.  Where do you stop?  And how does
> this all relate to WSDL operation definitions?  Rather than start down this
> slipperly slope, we decided to do the absolute minimum necessary for v1.0, and
> all we needed for v1.0 is description of a single input parameter.

     - The background to this might be a good item for the primer.

     - Consider publication techniques (box, footnotes) to include the
       rational and deeper information. E.g. don't push it to end.