Draft minutes from 6/22 conf call

[Doug Davis <dug@us.ibm.com>]

Minutes of OASIS WS-RX Teleconference
June 22, 2006
Start Time: 4:00pm EDT
Chair: Paul Fremantle

1 - Roll call - see Kavi
    Doug Davis agreed to take minutes

2 - Agenda approval
    Agenda: http://www.oasis-open.org/apps/org/workgroup/ws-rx/event.php?event_id=11217
    Suggestion on mailing list to defer
resolution of security issues since a lot
    of the active participants are not on
the call, plus work behind done 'off list'
    and is almost complete.  No objection.
    Agenda approved

3 - Approval of the 6/15 minutes:
    Minutes: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18881/MinutesWSRX-061506.html
    Matt Lovett moved to accept, Doug Davis
seconded
    No objection

4 - AI Review
    AI100 - http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1524
      Bob is nearly done will sending
something today
    AI102 - http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1562
      Marc: no change

5 - Conf Call Hosting
    Novell signed up for two weeks - July
6, July 13
    Bob/Hitachi signed up for July 20, July
27

    DougB: should we meet in July 6th? Lots
of vacation.
    PaulF: let's keep it and if there are
too many regrets then we can cancel

6 - Ack list in spec
    PaulF started a ballot - default must
be 'no'
    DougD added all non-observers to the
ack list - will remove 'no' votes after ballot
    PaulF: please send other names to the
chairs

7 - Schedule
    Paul: we're behind - let's move faster

8 - New Issues:
    NI01 - http://lists.oasis-open.org/archives/ws-rx/200606/msg00180.html
      From Jacques
      Accepted as a new issue

9 - Update From Editors:
    DougD: all resolved issues are in the
spec
    Added all people in the TC (except observers)
to the ack section, will remove people later

10 - Issues Discussion:

i129:
  DougD: latest proposal:
  http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00152.html
  Will remove RMD and fix typos noticed by MarcG
  Example of final text: 
      A value of "DiscardEntireSequence"
indicates that the entire Sequence
      MUST be discarded if the sequence
is closed, or terminated, 
      when there are one or more gaps
in the final SequenceAcknowledgement.
  MattL moves to accept - Bob 2nds
  No objection to unanimous consent


i130:
  DougD reviews issue (options - two variants
of new text and remove AckInterval)
  DougB: moves to remove AI from spec (proposed
by Bob thru email) - Bob 2nds
  PaulF: notes that he has customers that are
bothered there isn't a lot
         of guidance in the
spec w.r.t. timings
  PeterN: is it guidance or a normative requirement?
seems like it more of a hint
  PaulF: it is a hint but if we remove it perhaps
we need to provide some best 
         practices someplace
  Jacques: there are extension points in the
CSR so it can be added if people 
           want it -
but he agrees it is a useful bit of info. leave it to an 
           out-of-band
agreement
  No objection to unanimous consent on the
motion


i137:
  Anish reviews the issue:  http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i137
  New/smaller/more complete proposal sent by
PaulF:
    http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00173.html
  Anish drops his proposal in favor of Paul's
  Paul: new header is added just in response
to a MakeConnection and limited to the 
        criteria of that MakeConnection
- for this poll are there more messages or not
  Matt: asks for a link to the proposal
  Dug: moves to accept Paul's proposal - Anish,
2nds
  No objections - accepted

i121:
  Marc: Gil is working on revising it and will
have something for the TC soon/hopefully tomorrow

i122-124:
  Marc updated us on the security proposal status.
 Lots of meetings going on with the interested parties. Marc sent
a new proposal to the list. New issue he looked at - concern about use
of the STR - which referencing mechanism should/could be used?

  PaulF: can we close these out next week?
  Marc: should be able to - tried to address
all issues mentioned to the list

  Anish: some concern about the optionality of
the STR - thinks that might have been addressed now. Still worried about
the treatment of SSL.  Does understand the use-case of multiple tokens
in the message. Wonders if we should document this use-case. Should WS-SX
do something about this (SSL reference) or not? An issue is already in
WS-SX TC. This is not an RX-specific issue.

  DougB: There is a way to address this using
a WS-Trust mechanism

  Marc: No issue in the WSSX TC about an STR
pointing to the SSL - might be something that they could pick-up - looking
into how it can be filed as an issue.  Implicit vs explicit discussion
- a new line of text was added that calls this out to be an explicit reference.
 I76 in the WSSX TC: has concerns over that - how would it work?  Related
to SC only - so it would only apply to SC tokens (with what's in the body).
 If another spec wanted to use this then that spec would have to define
what it means.  Also loses the mU semantics. RMD needs a way to fault
when it can adhere to the security semantics.  Not sure how common
the security model they're proposing really is.

  Anish: DougB - what does 'this' mean?

  DougB: the use of one security context while
setting up sessions which will be run in a separate context - thought it
was issue 76

  Prateek (observer): trying to understand what
mechanisms the RX TC needs to invent to support this. Would like to see
this work done in WSSX.  re: Marc's comment about an SC solution is
just for SC - disagrees.

  Marc: how is issue 76 not just an SC thing?

  Prateek: this TC should profile it.  

  Marc: you're proposing making changes to SC,
so then this TC takes that pattern and do the same thing

  Prateek: no we take guidance from that TC

  Marc: you want to change the SC token - so
how can it be used with other token types?

  Prateek: not suggesting that a ref to SC token
can be used in other domain
 
  Anish: we need to do due diligence - this are
supposed to be composible specs - so if RX can solve it by profiling then
we should look at that - rather than inventing something new for RX.  this
is a common scenario (not just an RX issue) - we may not need to invite
something new here - or may - but we need to examine the options Tx has
the same issues

  PaulF: Prateek - some scenarios may be solved
by some other TC - and we should only address other scenarios that TC won't
cover - that will delay us and will still have to invent stuff

  Prateek - perhaps.  can't say for sure
that all of RX's requirements can be met by some other TC

  PaulF: perhaps its something we could take
on in a v2 version of this spec

  DaveO: Ideally, it would be nice if someone
solved our problem in our timeframe - we may need to profile it - that
would be goodness.  Doubts that the reqs we have are the exact same
for all other specs (e.g. Tx) - at some point we need to guess whether
SX will do what we want in the time we want.  Concerned about that.

  Anish: valid concern. But we're trying to create
composible specs - e.g. we're not reinventing policy - we're going to use
other specs.  This is in the same spirit of that.

  Marc: composible specs is a good argument.
 We use the token defined by some other spec - so why wait for some
other TC to define how to reference a Body instead of referencing a token?

  DaveO: How long does RX have before we need
to decide whether we're going to use what SX creates? How long until we
know what SX will create?

  Anish: Can't speak for the SX folks.  re:
composibility - sure its using SC but there may be other/better way to
do thing and we should look at them

  PaulF: agree, in general, with those that say
we should wait for SX - but its a bit late now - perhaps if it was 6 months
earlier.  Composibility is important but time to market is imporant
too.

  DaveO: Lots of options. Could do our own thing
- ok. Could wait and their quick - ok. They take a long time and we wait
- bad.  We wait,they're quick and it stinks - bad.  We create
our own and SX creates something similar but different - bad for customers.
 Whatever we end up doing we shouldn't stop our work as a risk mitigation
thing. We should do what's right for us in our schedule and spec

  PaulF: Prateek - you're an observer - I'm worried
about you not being a member if you're going to join into discussions like
this.

  Pratik: fair enough - if you'd prefer to wait
that's ok

  PaulF: if you're contributing ideas then we
may have IP issues

  Gil: re: Daveo's scenarios - not all that bad.
RSP could profile the SX's solution.

  Marc: This has been going on for a while -
these could have been raised earlier - to now say we should wait for SX
isn't a good idea for making progress. No proposal in the SX TC for this
right now - just a suggestion for an approach. Its just for SC - we would
need to then figure out how to use it for non-SC cases. If they end up
doing something really cool then RSP can profile its use.

  Anish: Its not too late - we've been discussing
it for a while.  This issue (security) has been raised late in the
TC so this proposal isn't that late in comparision. re:RSP - given how
WS-I operates I don't think its very realistic.  RSP is good - but
I don't expect anything contentious to be resolved by WS-I

  DougB: +1 to anish about raising issues. Not
sure what is being deferred.


i113: ran out of time
  

11 - Other business
     None