ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Draft minutes from 6/22 conf call
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 22 Jun 2006 18:39:44 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]