ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] Prelim minutes of 5/25 ws-rx conf call
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: "wsrx" <ws-rx@lists.oasis-open.org>
- Date: Fri, 26 May 2006 06:14:39 -0500
No, the SOAP processor doesn't *care*,
it just does what every SOAP processor is REQUIRED
to do, mU checking of headers targetted
to that node. How the configuration of the handlers is
managed is irrelevant.
Paul had it exactly right. You have
to do this for the RM elements anyway (and for every other
SOAP header that might possibly be decorated
with a mU=true).
Seriously Gil, with all due respect,
you are making a mountain out of a molehill and proposing
something that is more complex than
is needed.
I concur with Marc; this should be closed
with no action.
Cheers,
Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Gilbert Pilz" <Gilbert.Pilz@bea.com>
wrote on 05/25/2006 07:06:42 PM:
> But you are effectively *making* it care be requiring the higher-
> layer to register a unique SOAP header for every mU extension.
>
> - gp
>
> > -----Original Message-----
> > From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM]
> > Sent: Thursday, May 25, 2006 4:02 PM
> > To: Gilbert Pilz
> > Cc: Paul Fremantle; Christopher B Ferris; tom@coastin.com; wsrx
> > Subject: Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf call
> >
> > The SOAP processor doesn't have to care.
> >
> > The point is it doesn't have to know any of that nesting /
> > detailed information, Gil. The SOAP processor need only
care
> > that the named mU header is understood. "Understood"
only
> > has meaning to the handler and could easily mean "I can
grok
> > (random) extension foo in element bar when twiddle is false".
> > Doesn't seem any different from registering the handler
for
> > wsrm:CloseSequence in the first place from a SOAP processor
> > perspective.
> >
> > thanx,
> > doug
> >
> > On 25/05/06 15:55, Gilbert Pilz wrote:
> > > When you register the WS-RM headers with the SOAP processor
> > you weren't saying anything about the contents of those
> > headers, only that the SOAP processor should accept them. By
> > surfacing the mU semantics of WS-RM extensions as SOAP
> > headers you are linking the implementation details of a
> > particular SOAP extension to your general SOAP processor.
> > >
> > > Also, I can't see how extending something like
> > CloseSequence is "extending SOAP" in any meaningful
sense. An
> > extended CloseSequence and a non-extended CloseSequence both
> > live inside soap:Body. Why should the SOAP processor care
> > whether a child element of soap:Body has been extended (how
> > would it even know this was an extension w/out access to the
> > schema for that sub-element?) in some "semantically significant"
way?
> > >
> > > - gp
> > >
> > >
> > >> -----Original Message-----
> > >> From: Paul Fremantle [mailto:paul@wso2.com]
> > >> Sent: Thursday, May 25, 2006 3:29 PM
> > >> To: Gilbert Pilz
> > >> Cc: Christopher B Ferris; tom@coastin.com; wsrx
> > >> Subject: Re: [ws-rx] Prelim minutes of 5/25 ws-rx conf
call
> > >>
> > >> Gil
> > >>
> > >> RM already has to "register" headers with
the SOAP processor.
> > >> In fact every SOAP header author does. Thats just what
it takes to
> > >> write an extension to SOAP. Now you're suggesting that
we create a
> > >> new mechanism with exactly the same model - in RM. Hmmm.
> > Its a nice
> > >> model, but I don't like it enough to want it twice.
> > >>
> > >> Paul
> > >>
> > >> Gilbert Pilz wrote:
> > >>
> > >>> This means that you need to register every WS-RM
must-understand
> > >>> extension with the general SOAP processor. You're
coupling
> > >>>
> > >> your SOAP
> > >>
> > >>> configuration (via the Qname of the header that
refers to the
> > >>> extension) to the internal details of the messages
(e.g. a
> > >>>
> > >> particular
> > >>
> > >>> extension to CloseSequence) that will be carried
within SOAP.
> > >>> Extensions to WS-RM-defined messages should be handled
at
> > the WS-RM
> > >>> layer and not surfaced to the general SOAP processor.
> > >>> - gp
> > >>>
> > >>>
> > >>>
> > >> --------------------------------------------------------------
> > >> ----------
> > >>
> > >>> *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > >>> *Sent:* Thursday, May 25, 2006 3:04
PM
> > >>> *To:* tom@coastin.com
> > >>> *Cc:* wsrx
> > >>> *Subject:* Re: [ws-rx] Prelim minutes
of 5/25 ws-rx conf call
> > >>>
> > >>>
> > >>> From below:
> > >>> Doug B: (from chat) concretely: use
a
> > soap:mustUnderstand header
> > >>> which is handled using normal SOAP
processing model, the given
> > >>> element's qname would be associated
with semantics
> > >>>
> > >> defined in the
> > >>
> > >>> relevant WS-RM extension, the SOAP
processor doesn't
> > >>>
> > >> have to know
> > >>
> > >>> the details of this extension just
that a handler knows
> > >>>
> > >> what to do
> > >>
> > >>> +1
> > >>>
> > >>> I have tried to make this point repeatedly
in the past.
> > >>>
> > >> The whole
> > >>
> > >>> point of the SOAP header
> > >>> with mU=true is just to test that
the extension is understood.
> > >>> Nothing more, nothing less. It need
not
> > >>> reference an explicit instance of
the extension. It is merely
> > >>> there to say: if the processor doesn't
> > >>> know what to do with this extension,
DO NOT process
> > >>>
> > >> this message.
> > >>
> > >>> Cheers,
> > >>>
> > >>> Christopher Ferris
> > >>> STSM, Software Group Standards Strategy
> > >>> email: chrisfer@us.ibm.com
> > >>> blog:
> > >>>
> > >> http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> > >>
> > >>> phone: +1 508 377 9295
> > >>>
> > >>> Tom Rutt <tom@coastin.com> wrote
on 05/25/2006 05:40:54 PM:
> > >>>
> > >>> > Prelim minutes 5/25 attached.
> > >>> >
> > >>> > Please post any corrections to
entire list before
> > >>>
> > >> monday morning.
> > >>
> > >>> >
> > >>> > Tom Rutt
> > >>> >
> > >>> > --
> > >>> > ----------------------------------------------------
> > >>> > Tom Rutt email: tom@coastin.com;
trutt@us.fujitsu.com
> > >>> > Tel: +1 732 801 5744 Fax: +1
732 774 5133
> > >>> >
> > >>> >
> > >>> > Prelim Minutes of OASIS WS-RX
Teleconference
> > >>> > May 25, 2006
> > >>> >
> > >>> > Start Time:4:00 PM Eastern Daylight
Time
> > >>> >
> > >>> > Sanjay acted as chair.
> > >>> >
> > >>> > Textual Conventions
> > >>> >
> > >>> > Ø Action Item
> > >>> > Motion
> > >>> > § Resolution
> > >>> >
> > >>> > 1 Roll Call
> > >>> > From Kavi:
> > >>> >
> > >>> > Over 32 of 46 voting members,
meeting is quorate
> > >>> >
> > >>> > Tom Rutt agreed to take minutes.
> > >>> > 2 Agenda Approval
> > >>> > Agenda
> > >>> > 1) Roll Call
> > >>> >
> > >>> > 2) Review and approval of the
agenda
> > >>> >
> > >>> > 3) Approval of the May 18, 2006
meeting minutes
> > >>> > http://www.oasis-open.org/committees/download.
> > >>> > php/18295/MinutesWSRX-051806.html
> > >>> >
> > >>> > 4) AI Review
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_ite
> > >> m
> > >>
> > >>> s.php
> > >>>
> > >>> >
> > >>> > 5) New issues since last conf-call
> > >>> > Watch for Marc's email
> > >>> >
> > >>> > 6) Review of changes due to i093
> > >>> >
> > >>>
> > >> http://lists.oasis-open.org/archives/ws-rx/200605/msg00117.html
> > >>
> > >>> >
> > >>>
> > >> http://lists.oasis-open.org/archives/ws-rx/200605/msg00205.html
> > >>
> > >>> >
> > >>> > 7) Issue Discussion:
> > >>> > a> i121 security threats and
requirements
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 21
> > >>>
> > >>> > b> i122 security profiles
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 22
> > >>>
> > >>> > c> i124 security composition
policy
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 24
> > >>>
> > >>> > d> i123 security profile agreement
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 23
> > >>>
> > >>> > e> i115 "must understand"
attribute for extensions to
> > >>>
> > >> RM components
> > >>
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 15
> > >>>
> > >>> > 8) Any other business
> > >>> >
> > >>> > Marc G asked about issue 119.
Also 125 seems ready.
> > >>> >
> > >>> > Sanjay: Doug D is not on the
call, but since 125 was
> > >>>
> > >> not included I
> > >>
> > >>> > would put it at end.
> > >>> >
> > >>> > Marc: could 115 be put before
the security issues?
> > >>> >
> > >>> > No objections to place 115 before
security issues.
> > >>> >
> > >>> > 3 Approval of the 5/18 minutes;
> > >>> > http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.
> > >>> > php/18243/MinutesWSRX-051106.html
> > >>> >
> > >>> > Tom moved, Marc G seconded to
approve 5/18 minutes.
> > >>> >
> > >>> > § No objection minutes for 5/18
meeting approved.
> > >>> >
> > >>> > 4 AI Review
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_ite
> > >> m
> > >>
> > >>> s.php
> > >>>
> > >>> >
> > >>> > #0100: Tom Rutt & Bob volunteered
to work on state
> > >>>
> > >> table revisions
> > >>
> > >>> > with Jacques
> > >>> > Owner: Jacques Durand
> > >>> > Status: Still Open
> > >>> > Assigned: 2006-05-09
> > >>> > Due: ---
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > ---------------------------------------------------------------------
> > >> -
> > >>
> > >>> ----------
> > >>>
> > >>> >
> > >>> > #0102: Marc G will prepare to
start an issues list
> > for Public
> > >>> reviewcomments
> > >>> > Owner: Marc Goodner
> > >>> > Status: Still Open
> > >>> > Assigned: 2006-05-22
> > >>> > Due: ---
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > ---------------------------------------------------------------------
> > >> -
> > >>
> > >>> ----------
> > >>>
> > >>> >
> > >>> > #0103: Paul F will address Marc
G concerns and
> > >>>
> > >> interop concerns in a
> > >>
> > >>> > next version of schedule, including
the member ballot
> > >>> > Owner: Paul Fremantle
> > >>> > Status: Still Open
> > >>> > Assigned: 2006-05-22
> > >>> > Due: ---
> > >>> > 5 New issues since last conf-call
> > >>> > none
> > >>> >
> > >>> > 6 Review of changes due to i093
> > >>> >
> > >>>
> > >> http://lists.oasis-open.org/archives/ws-rx/200605/msg00117.html
> > >>
> > >>> >
> > >>>
> > >> http://lists.oasis-open.org/archives/ws-rx/200605/msg00205.html
> > >>
> > >>> >
> > >>> > Sanjay: there was considerable
discussion on the list
> > >>>
> > >> about this.
> > >>
> > >>> >
> > >>> >
> > >>>
> > >> http://lists.oasis-open.org/archives/ws-rx/200605/msg00263.html
> > >>
> > >>> >
> > >>> > Doug B: There seems to be agreement
on a small number
> > >>>
> > >> of changes to
> > >>
> > >>> > satisfy Marc G. I propose we
accept Gils document
> > >>>
> > >> with the small
> > >>
> > >>> > number of changes Marc G and
I agreed on, and include
> > >>>
> > >> this as our
> > >>
> > >>> > base document.
> > >>> >
> > >>> > Anish: I have a preference for
an alternative
> > >>>
> > >> proposal that I sent.
> > >>
> > >>> > It might be better to not use
the MUST/MAY OPTIONAL
> > keywords.
> > >>> > http://www.oasis-open.org/apps/org/workgroup/ws-
> > >>> > rx/email/archives/200605/msg00266.html
> > >>> > I have an alternate proposal:
> > >>> >
> > >>> > Replace the offending parts with
assertions that do
> > >>>
> > >> not contain
> > >>
> > >>> any 2119
> > >>> > key words --
> > >>> > The cardinality of this [element|attribute]
is [zero
> > >>>
> > >> or more|one or
> > >>
> > >>> > more|exactly one].
> > >>> >
> > >>> > -Anish
> > >>> >
> > >>> > Gil: I agree with Anish, we can
use xml schema language for
> > >>> > cardinalities, avoiding the rfc
2119 keywords.
> > >>> >
> > >>> > Marc G: this is inconsistent
with the rest of the
> > >>>
> > >> document. It would
> > >>
> > >>> > suggest multiple changes elsewhere.
I prefer the
> > proposal from
> > >>> > myself and Doug. The text that
Doug and I propose
> > continues to
> > >>> > describe the elements themselves,
without cardinality.
> > >>> >
> > >>> > Anish: you can just get rid of
existing improper 2119
> > >>>
> > >> terms, and
> > >>
> > >>> > replace with simple cardinality
statements in English.
> > >>> >
> > >>> > Doug B moved to accept proposal
from Marc and himself, Marc
> > >>> Seconded.
> > >>> >
> > >>> > Anish: speaks against it, since
it states conformance
> > >>> constraints twice.
> > >>> >
> > >>> > Doug B: in a particular change
around wsrm:acksTo,
> > >>>
> > >> the rfc 2119
> > >>
> > >>> > language is about actions rm
source must do and
> > >>>
> > >> constraints on the
> > >>
> > >>> > type. It is also about how the
rm destination must
> > >>>
> > >> respond. They
> > >>
> > >>> > are not about cardinality.
> > >>> >
> > >>> > Vote:
> > >>> > 13 Yes
> > >>> > 6 No
> > >>> >
> > >>> > § Motion passed to accept proposal
from Marc and Doub
> > >>>
> > >> F to close
> > >>
> > >>> Issue 093.
> > >>> >
> > >>> > Discussion on availability of
Next working draft.
> > >>> >
> > >>> > Gil: if we do not include issues
we resolve today, we can be
> > >>> ready soon.
> > >>> >
> > >>> > Sanjay: It should be ok to not
include issues resolve
> > >>>
> > >> on today's
> > >>
> > >>> call.
> > >>> >
> > >>> > Marc G: the next wd will include
all pending issues.
> > >>> >
> > >>> > Bob F: also must include issue
93.
> > >>> >
> > >>> > Gil: we should have one available
by cob Tuesday.
> > >>> >
> > >>> > Anish: do we have exact text
for Issue 96.
> > >>> >
> > >>> > Bob: issue 113 is based on an
interim spec from Gil.
> > >>> >
> > >>> > Tom: those state tables came
from an email from the Face to
> > >>> Face, from Matt.
> > >>> >
> > >>> > Bob F: Jacques and I are eagerly
awaiting a new draft
> > >>>
> > >> which resolves
> > >>
> > >>> > closed issues, to insert clause
numbers in the state table.
> > >>> > 7 Issue Discussion:
> > >>> >
> > >>> > 7.1 I 115
> > >>> >
> > >>> > Gil: an updated proposal from
may 3 is at:
> > >>>
> > >> http://lists.oasis-open.
> > >>
> > >>> > org/archives/ws-rx/200605/msg00025.html
> > >>> >
> > >>> > Gil: if other side does not understand
the extension,
> > >>>
> > >> the sender
> > >>
> > >>> > must know that. We need some
inditcation. This
> > >>>
> > >> proposal defines a
> > >>
> > >>> > wsrm specific attribute, to be
used at the top level
> > >>>
> > >> (only) of an
> > >>
> > >>> > extension element, and we define
a
> > >>>
> > >> wsrm:mustunderstand Fault to use
> > >>
> > >>> > if the receiver does not understand
that extension.
> > I added a
> > >>> > statement that the attribute
cannot be used below the
> > >>>
> > >> top element.
> > >>
> > >>> >
> > >>> > Paul C: I am opposed to this.
Soap already has a must
> > >>>
> > >> understand
> > >>
> > >>> > model, and having wsrm add this
is not the way to
> > go. I would
> > >>> > rather add a soap header which
states there is an
> > >>>
> > >> extension element
> > >>
> > >>> > being used, with a soap:mustUnderstand
attribute.
> > >>> >
> > >>> > Anish: I disagree that this is
not independent of the soap
> > >>> > processing model. This wsrm:mustUnderstand
attribute
> > >>>
> > >> is checked
> > >>
> > >>> > after the soap model does what
it does.
> > >>> >
> > >>> > Gil: I have a problem with a
new empty soap header,
> > >>>
> > >> with a reference
> > >>
> > >>> > to an extension used in another
place. I think putting wsrm
> > >>> > semantics into the soap processing
layer is not valid. It is
> > >>> > semantically wrong to use soap
must understand,
> > since there is
> > >>> > nothing wrong at the soap leve.
The processing is
> > >>>
> > >> better done at
> > >>
> > >>> > the WSRM level.
> > >>> >
> > >>> > Paul F: you could use a separate
entity in a soap
> > >>>
> > >> header. There
> > >>
> > >>> > could be work around, but the
general soap model
> > >>>
> > >> allows the complex
> > >>
> > >>> > case. Since I have not yet seen
extensions proposed
> > >>>
> > >> yet, I think
> > >>
> > >>> > this is something for version
2. I prefer we defer
> > this issue
> > >>> > resolution to a future version
of the spec.
> > >>> >
> > >>> > Sanjay: I agree this should be
deferred.
> > >>> >
> > >>> > Doug B: (from chat) concretely:
use a
> > >>>
> > >> soap:mustUnderstand header
> > >>
> > >>> > which is handled using normal
SOAP processing
> > model, the given
> > >>> > element's qname would be associated
with semantics
> > >>>
> > >> defined in the
> > >>
> > >>> > relevant WS-RM extension, the
SOAP processor doesn't
> > >>>
> > >> have to know
> > >>
> > >>> > the details of this extension
just that a handler
> > >>>
> > >> knows what to do
> > >>
> > >>> >
> > >>> > Marc G: I agree with Doug B proposal
on chat.
> > >>> >
> > >>> > Gil: with some of our security
extensions, it would
> > >>>
> > >> be better to not
> > >>
> > >>> > close sequence if the receiver
does not understand a
> > >>>
> > >> requirement
> > >>
> > >>> > needed by the requester for that
sequence. I do not
> > >>>
> > >> want to tightly
> > >>
> > >>> > couple a general soap processing
engine with the wsrm
> > >>> implementation.
> > >>> >
> > >>> > Sanjay: we should defer this
issue since we do not yet have
> > >>> extensions.
> > >>> >
> > >>> > Umit: I would prefer this issue
to be deferred to a later
> > >>> version ofthe spec.
> > >>> >
> > >>> > Paul F: Gil stated the security
composition profile
> > >>>
> > >> might need such
> > >>
> > >>> > a mechanism. Is this intended
to be outside the spec.
> > >>> >
> > >>> > Gil: I want that to be within
this spec.
> > >>> >
> > >>> > Paul F: then I think even more
we should defer this.
> > >>>
> > >> Why build in
> > >>
> > >>> > features when we do not have
a use case in the spec
> > that needs
> > >>> them.
> > >>> >
> > >>> > Gil: It is unfair to require
extensions to already
> > >>>
> > >> exist before we
> > >>
> > >>> > have such a mechanism.
> > >>> >
> > >>> > Paul C: I would like to have
it be clarified if Gil's
> > >>>
> > >> proposal for
> > >>
> > >>> > issue 123 requires this proposed
solution.
> > >>> >
> > >>> > Sanjay: I would like to wait
to answer this question
> > >>>
> > >> until after we
> > >>
> > >>> > discuss issue 123.
> > >>> >
> > >>> > Sanjay: I propose we defer resolution
of 115 until
> > >>>
> > >> after we discuss
> > >>
> > >>> > the security related issues.
> > >>> >
> > >>> >
> > >>> > 7.2 i121 security threats and
requirements
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 21
> > >>>
> > >>> >
> > >>> > Gil: we need to realize that
the sequence is a shared
> > >>>
> > >> resource which
> > >>
> > >>> > is being protected. I need to
make sure the
> > sequence ack comes
> > >>> > from the RMD which "owns"
that sequence. This needs to be
> > >>> explained.
> > >>> >
> > >>> > Gil: the existing text also has
unnecessary details.
> > >>>
> > >> I just got
> > >>
> > >>> > around to rewriting chaper 5.
at: http://lists.oasis-open.
> > >>> > org/archives/ws-rx/200605/msg00096.html
> > >>> >
> > >>> > Gill review the threats which
must be dealt with.
> > >>> >
> > >>> > Gil: sequence hijacking is not
the same as a session
> > >>>
> > >> identifier.
> > >>
> > >>> >
> > >>> > Gil: the text on message correlation
threats (in
> > 5.4) might be
> > >>> > better to remove altogether.
> > >>> >
> > >>> > Paul F: I think this is basically
a good rewrite,
> > >>>
> > >> although I am not
> > >>
> > >>> > a security expert. It uses terminology
"integrity
> > >>>
> > >> protected", and
> > >>
> > >>> > it is not clear what this means.
Could that be added
> > >>>
> > >> to a glossary?
> > >>
> > >>> >
> > >>> > Gil: I agree that should be added
to a glossary.
> > >>> >
> > >>> > Paul F: I think we could accept
this proposal, with
> > >>>
> > >> removal of 5.4.
> > >>
> > >>> >
> > >>> > Paul C: The 8 requirements in
the proposal in 5.5, do
> > >>>
> > >> not correlate
> > >>
> > >>> > back to the text on the 4 or
5 threats. If I only
> > >>>
> > >> want to worry
> > >>
> > >>> > about sequence hijacking, I do
not know which of
> > the items in
> > >>> 5.5 apply.
> > >>> >
> > >>> > Gil: That is a good point, not
everyone is worried
> > about every
> > >>> > threat. The relationship between
the threats an security
> > >>> > requirements needs to be clarified.
I would like to
> > >>>
> > >> take an action
> > >>
> > >>> > item to come up with a new version
which does that.
> > >>> >
> > >>> > Ø Action: Gill will clarify his
proposal for i121 to
> > >>>
> > >> clarify the
> > >>
> > >>> > relationship between requirements
and the threats.
> > >>> > Doug D: I am not ready to make
a final decision until
> > >>>
> > >> we see the
> > >>
> > >>> > result of this action item. I
would like perhaps a
> > >>>
> > >> straw poll on
> > >>
> > >>> > whether Gil should bother to
carry out this action
> > >>>
> > >> item to come up
> > >>
> > >>> > with a new proposal addressing
the concerns raised on
> > >>>
> > >> this call.
> > >>
> > >>> >
> > >>> > Sanjay: straw poll Yes means
continue to work, no
> > >>>
> > >> means to not have
> > >>
> > >>> > Gill Bother to update the proposal.
> > >>> >
> > >>> > No opposition to having Gil work
on action item.
> > >>> >
> > >>> > Paul C: he has threats, and requirements
> > (solutions). I would
> > >>> > prefer to have three sections,
threats, potential
> > >>>
> > >> countermeasures,
> > >>
> > >>> > and which countermeasure is used
for each threat. The
> > >>>
> > >> WSI has a
> > >>
> > >>> > document which demonstrates this.
> > >>> >
> > >>> > Gil : I agree with Paul C.
> > >>> >
> > >>> > Sanjay: we should continue post
questions to the mail list.
> > >>> >
> > >>> >
> > >>> > Gil: it might not be ready by
next week call. The
> > earlier the
> > >>> > better for any email to the list.
Two weeks is
> > >>>
> > >> probable too long a
> > >>
> > >>> > time to wait. It would be better
to be done before the next
> > >>> meeting.
> > >>> > 7.3 b> i122 security profiles
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 22
> > >>>
> > >>> >
> > >>> > Gil reviewed his proposal posted
as http://lists.oasis-open.
> > >>> > org/archives/ws-rx/200605/msg00097.html
> > >>> >
> > >>> > Gil: a profile does several things:
> > >>> > How rms and rmd authenticate
each other when sequence
> > >>>
> > >> is created.
> > >>
> > >>> > For every message in sequence
(traffic or control)
> > >>>
> > >> how they know who
> > >>
> > >>> > sent the message or inserted
the header.
> > >>> >
> > >>> > Gil: I see three sets of profiles
> > >>> > Tls and other authendication
> > >>> > Tls and tls authentication
> > >>> > Ws secure conversation.
> > >>> >
> > >>> > Gil: there is different concerns
about RMS
> > >>>
> > >> authentication and AS
> > >>
> > >>> > authentication. I would like
other peoples opinion on this
> > >>> proposal.
> > >>> >
> > >>> > Marc concern on web chat: I don't
understand the TLS
> > >>>
> > >> uris, aren't
> > >>
> > >>> > you already connected over TLS
by the time you are
> > >>>
> > >> signaling you
> > >>
> > >>> areusing it?
> > >>> >
> > >>> > Marc: why does the RMS need to
know whether the
> > >>>
> > >> security applies to
> > >>
> > >>> > its code or the application's
code.
> > >>> >
> > >>> > Gil: if RMD is a separate node,
it must ensure the
> > >>>
> > >> identity of AS
> > >>
> > >>> > flows to the AD. It is necessary
for composability.
> > >>> >
> > >>> > Paul C: This proposal for 122
is used in solution for 123.
> > >>> >
> > >>> > Gil: the ability of two ends
to know how to protect WSRM is
> > >>> > important. This can be done out
of band. 123 is about
> > >>>
> > >> the run time
> > >>
> > >>> > agreement for those profiles.
122 is just about
> > >>>
> > >> coming up with a
> > >>
> > >>> > way for two people to agree on
that they are using for wsrm.
> > >>> >
> > >>> > Paul C: these profiles are collections
of polices
> > >>>
> > >> which and be used
> > >>
> > >>> > out of band. Why not use ws-security
policy.
> > >>> >
> > >>> > Ran out of time.
> > >>> >
> > >>> > Sanjay: continue to discuss security
concerns on the list.
> > >>> > 7.4 c> i124 security composition
policy
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 24
> > >>>
> > >>> > no time to discuss
> > >>> > 7.5 d> i123 security profile
agreement
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i
> > >> 1
> > >>
> > >>> 23
> > >>>
> > >>> > no time to discuss
> > >>> >
> > >>> > 8 Any other business
> > >>> > none
> > >>> >
> > >>>
> > >>>
> > >> ______________________________________________________________
> > >> _________
> > >>
> > >>> > Notice: This email message, together
with any
> > attachments, may
> > >>> contain
> > >>> > information of BEA Systems, Inc.,
its subsidiaries
> > >>>
> > >> and affiliated
> > >>
> > >>> > entities, that may be confidential,
proprietary,
> > >>>
> > >> copyrighted and/or
> > >>
> > >>> > legally privileged, and is intended
solely for the
> > use of the
> > >>> individual
> > >>> > or entity named in this message.
If you are not the intended
> > >>> recipient,
> > >>> > and have received this message
in error, please immediately
> > >>> return this
> > >>> > by email and then delete it.
> > >>>
> > >>>
> > >> --
> > >>
> > >> Paul Fremantle
> > >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >>
> > >> http://feeds.feedburner.com/bloglines/pzf
> > >> paul@wso2.com
> > >>
> > >> "Oxygenating the Web Service Platform", www.wso2.com
> > >>
> > >>
> > >>
> >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]