RE: [ws-rx] Prelim minutes of 5/25 ws-rx conf call

[Christopher B Ferris <chrisfer@us.ibm.com>]

And this is a problem, why? The fact
is, that you do NOT need to register every
RM extension, only those that MUST be
understood for correct processing to 
be ensured.

Are you envisaging a kagillion extensions?
I certainly don't forsee such a circumstance.
I also don't see registering the extension
QNames with the SOAP processor to be a problem.

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 06:23:04 PM:

> 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_items.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#i121
> > b> i122 security profiles 
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122
> > c> i124 security composition policy 
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i124
> > d> i123 security profile agreement 
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123
> > e> i115 "must understand" attribute for extensions
to RM components 
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i115
> > 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_items.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#i121
> >   
> > 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#i122
> >   
> > 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#i124
> > no time to discuss 
> > 7.5      d> i123 security profile agreement
> > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123
> > 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.