Re: [ws-rx] WS-RX draft minutes 2007-03-01 are attached

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

+1

This was my recollection/understanding
as well.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

Paul Fremantle <paul@wso2.com> wrote on 03/02/2007
02:59:47 AM:

> Bob
> 
> After we successfully closed issue 40 I restated that the electronic
> ballot would include WSMC as well. I also asked if the editors could
> produce updated specs including all the changes and they (Dug) agreed
> they could.
> 
> Please can you update the minutes to include those.
> 
> Paul
> 
> Bob Freund-Hitachi wrote:
> >  
> > 
> >  
> > 
> >  
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > Hide IRC
> > 
> > OASIS Logo <http://www.oasis-open.org.org/>
> > 
> > 
> >   - DRAFT -
> > 
> > 
> >   ws-rx Teleconference
> > 
> > 
> >     01 MAR 2007
> > 
> > 
> >       Attendees
> > 
> > Chair
> >     Paul Fremantle
> > Scribe
> >     Bob Freund
> > 
> > ------------------------------------------------------------------------
> > 
> > 
> >       Contents
> > 
> > <#topics>Topics
> >     [1] <#d1e18>  approval of 2007-02-18
minutes 
> >     [2] <#d1e22>  Action Items 
> >     [3] <#d1e26>  Schedule 
> >     [4] <#d1e68>  A word from the editors..
> >     [5] <#d1e82>  pr40 Policy assertion
> >     [6] <#d1e294>  PR41 
> >     [7] <#d1e334>  return to pr40 
> > Table of Resolutions <#resolutions>
> > Table of Action Items <#ais>
> > 
> > ------------------------------------------------------------------------
> > 
> > 
> >       Action Items
> > 
> > New:
> > 
> > ------------------------------------------------------------------------
> > 
> > 
> >       Resolutions
> > 
> >     * 2007-03-01-1 <#d1e20>: minutes approved
without objection
> >     * 2007-03-01-2 <#d1e329>: motion [1] passes
16 to 4
> >     * 2007-03-01-3 <#d1e377>: electronic ballot
will be started for rm
> >       and rmp without objection
> >     * 2007-03-01-4 <#d1e392>: motion [2] passes
without objection
> > 
> > ------------------------------------------------------------------------
> > 
> > 
> >       Minutes
> > 
> > Scribe: Bob Freund
> > 
> > 
> >       approval of 2007-02-18 minutes
> > 
> > *Resolution: *minutes approved without objection
> > 
> > 
> >       Action Items
> > 
> >  
> > -- none --
> > 
> > 
> >       Schedule
> > 
> > Paul:
> > Has begun to pull together the submission package
> >  
> > ... There are now three certifications, so that is enought for
a submission
> > Martin:
> > The new process requires that there be an interop statement in
the 
> > certification
> > MarcG:
> > It does not appear on the web site
> > Martin:
> > It has not been updated on the web site, but goes into effect
today.
> >  
> > ... It should be posted but it is not. Perhaps OASIS staff knows
what 
> > has happened to it.{edited}
> > <Pete Wenzel>
> > March 1 TC Process change announcement is at 
> > http://lists.oasis-open.org/archives/chairs/200702/msg00001.html
> > <Dug>
> > I say/ move forward as is
> > <Dug>
> > and let the TC admin complain
> > <Mr. Goodner>
> > We could all just reply to our own notes that we have used them
in 
> > interop activites
> > <Pete Wenzel>
> > dd. "Statement of Use", with respect to a specification,
is a written 
> > statement by
> > an OASIS Organizational Member stating that it is successfully
using or
> > implementing that specification in accordance with the conformance
clauses
> > specified in Section 2.18, and stating whether its use included
the
> > interoperation of multiple independent implementations.
> > Martin:
> > TC admin might call us on this if the statement is not included.
> > <Pete Wenzel>
> > Note that the wording doesn't require interop, just that you
state 
> > "whether" interop occurred. The answer could be, "no".
> > PaulF:
> > suggests that we might not shoot the messanger in this case.
> >  
> > ... The current sheddewl is that we will close all issues today
> > 
> > 
> >       A word from the editors..
> > 
> > Dug:
> > Moved from OO to word for the purpose of facilitating conversion
to html
> > <Martin>
> > is it ODF compliant?
> > <Mr. Goodner>
> > Word has an ODF impot plugin
> > <chris>
> > lost in translation?
> > MarcG:
> > all of the details of the conversion is available on the editor's
email 
> > list.
> >  
> > ... there were very few problems
> > 
> > 
> >       pr40 Policy assertion
> > 
> > TomR:
> > I sent out a proposal this morning.(with explanation)
> > <anish>
> > can someone talk about what happens when the assertion is absent
in one 
> > of the policy alternative but present in other
> >  
> > ... I see that there has been additional discussions concerning
if the 
> > policy can be attached to messages as well.
> > <Dug>
> > link to the pdf i sent: 
> > http://www.oasis-open.org/apps/org/workgroup/ws-
> rx/email/archives/200702/msg00066.html
> > <anish>
> > as well as what happens when the assertion is absent altogether
> > Dug:
> > My only concern with the text proposed by tom is the "required"
from 
> > this endpoint portion
> >  
> > ... want to permit that a mixture of mc and non-mc be permitted
> > <chris>
> > I'm having a Horshack moment
> > chris:
> > when behavior is mandated, then it is important that the behavior
is 
> > defined in terms of requirements
> >  
> > ... All we need to say is "here it is, go to town".
> >  
> > ... wsp:optional is a red-herring, and is just a short-hand
> >  
> > ... we get to say what we intend the requirement to mean.
> >  
> > A policy has a vocabulary
> >  
> > a policy consists of a set of assertions that uses the vocabulary
> >  
> > a set of assertions that says nothing about a term not in the
> > vocabulary, says nothing about that term
> >  
> > when set operationa are performed between a set of assertions
and a set 
> > of alternatives
> >  
> > there are two cases generated
> >  
> > assertion in the vocabulary, but not in an assertion, then it
mean "you 
> > shall not"
> >  
> > if term is not in the policy, then there is no statement
> > chris:
> > Provides explanation of the operation of policy intersection
operation 
> > and scope...
> > <anish>
> > if the subject is endpoint, doesn't it apply to all messages?
> > <Dug>
> > 
> > <wspolicy>
> > <wsp:ExactlyOne>
> > <wsp:All>
> > <wsa:Addressing>
> > <wsa:AnonymousResponses/>
> > </wsa:Addressing>
> > </ws:All>
> > <wsp:All>
> > <wsa:Addressing>
> > <wsa:NonAnonymousResponses/>
> > </wsa:Addressing>
> > <wsmc:MCSupported/>
> > </ws:All>
> > </wsp:ExactlyOne>
> > </wspolicy>
> > <chris>
> > yed. that is the policy... or this one:
> > <chris>
> > <wspolicy>
> > <wsp:ExactlyOne>
> > <wsp:All>
> > <wsa:Addressing>
> > <wsa:AnonymousResponses/>
> > </wsa:Addressing>
> > </ws:All>
> > <wsp:All>
> > <wsa:Addressing/>
> > <wsmc:MCSupported/>
> > </ws:All>
> > </wsp:ExactlyOne>
> > </wspolicy>
> > Gil:
> > Looks like there may be an issue for a policy for replys to be
the mc 
> > uri and faultto: being the anon uri
> > <Gil>
> > FWIW I think the second policy is inconsistent
> > <chris>
> > inconsistent with what?
> > <Gil>
> > "<wsa:Addressing/>" by itself means "no
responses"
> > <chris>
> > no, it does not
> > <Gil>
> > since the absence of Anon means "no Anon"
> > <chris>
> > the second is saying not to use the anon URI
> > <Gil>
> > and theabsence of "NonAnon" means "only Anon"
> > <chris>
> > I Got You, Babe
> > <chris>
> > no, it does not
> > <Gil>
> > ok, well then forget the whole thing
> > <chris>
> > in the second policy statement above, the absence of wsa:NonAnon
from 
> > the policy vocabulary expressly says NOTHING about non-anonymous
> > Anish:
> > wsa considers both replyTo and FaultTo as response uris.
> > <Dug>
> > 
> > <wspolicy>
> > <wsp:ExactlyOne>
> > <wsp:All>
> > <wsa:Addressing>
> > <wsa:AnonymousResponses/>
> > </wsa:Addressing>
> > </ws:All>
> > <wsp:All>
> > <wsa:Addressing/>
> > </ws:All>
> > </wsp:ExactlyOne>
> > </wspolicy>
> > <Dug>
> > What about this?
> > <wspolicy>
> > <wsp:ExactlyOne>
> > <wsp:All>
> > <wsa:Addressing>
> > <wsa:AnonymousResponses/>
> > </wsa:Addressing>
> > </ws:All>
> > <wsp:All>
> > <wsa:Addressing/>
> > </ws:All>
> > </wsp:ExactlyOne>
> > <MCAssertion/>
> > </wspolicy>
> > <Gil>
> > Chirs: I don't understand what you mean when you say that wsam:/NonAnon
> > is not part of the policy vocabulary
> > PaulF:
> > seems that we will not resolve this issue tonight
> > <Dug>
> > the presence of the MCassertion is orthogonal to the WSA assertion
> > <Gil>
> > Dug: that's my whole point! - its not really
> > <Dug>
> > sure it is
> > <anish>
> > not quite dug. u can't have MC assertion along with AnonmousResponse
in 
> > teh same alternative
> > <Gil>
> > the MC anon URI falls into the bucket of "non-Anon URIs"
> > <Dug>
> > yes you can because the MCanonURI could be used on some non-WSA
EPR
> > MarcG:
> > It seems to me that there is not too much difference between
views. 
> > Perhaps resolution today is possible
> > 
> > 
> >       PR41
> > 
> > Martin:
> > I do not think that it is appropriate to reference the member
submission 
> > of policy
> > <Mr. Goodner>
> > My proposal http://www.oasis-open.org/archives/ws-rx/200703/msg00021.html
> >  
> > ... if the policy wonks on the call claim that it is backward
> > compatible, then we might just update the references
> > Ashok:
> > Why is it so difficult to update the reference? The CR version
is 
> > significantly different from the submission.
> > Anish:
> > I like the second part of Marc's proposal above, but I don't
like the 
> > point of using an assertion with any version of policy.
> >  
> > ... that mitigates against interoperability. We need to be very
clear as 
> > to which spec is normatively references.
> > MarcG:
> > I think that these assertions would work with both 1.2 and 1.5.
I don't 
> > see a problem with referencing both.
> > Martin:
> > If the cr version is backward compatible with the submission,
then I 
> > have no problem with fixing the references in the spec.
> > PaulF:
> > Seems to me that updating the reference to the cr version would
be the 
> > shortest path, I am slightly in favor of it.
> > <Ashok>
> > +1
> > chris:
> > Pointing to the transition request (lc to cr), the WG said that
there 
> > were no substantive changes other than perhaps locking down the
> > namespace to the final form.
> >  
> > ... as for 1.2, they are consistent, but I am not sure that they
are 
> > backward compatible; there is stuff in the cr version that is
not in 1.2
> > <anish>
> > update the WSP normative reference to the CR version and change
the 
> > policy NS to the CR namespace
> >  
> > text by anish above is [1]
> > <chris>
> > +1
> >  
> > voting proceeds due to objection my MarcG.
> > *Resolution: *motion [1] passes 16 to 4
> > <Dug>
> > The MakeConnection policy assertion indicates that the MakeConnection
> > protocol (operation and the use 2 of the MakeConnection URI template
in 
> > EndpointReferences) is required for messages exchanged with this
> > endpoint. This assertion has Endpoint Policy Subject [WS-PolicyAttachment].
> > 
> > 
> >       return to pr40
> > 
> > Anish:
> > the subject is endpoint, so that this will apply to all messages
to the 
> > endpoint.
> > <chris>
> > we are reading too much into this
> > Dug:
> > uh huh
> > <Dug>
> > "To indicate Make Connection protocol, is supported, but
not required
> > for all instances of messages sent from an endpoint, the MakeConnection
> > assertion can be marked with the Optional=true attribute value."
> > <Paul Fremantle>
> > should it be wspptional
> > <anish>
> > may be an example
> > <anish>
> > instead of a stmt
> > <chris>
> > I think that the spec should say nothing
> > <anish>
> > dug, why don't u make a motion with that change?
> > <anish>
> > assuming that is acceptable to folks
> > <Dug>
> > The MakeConnection policy assertion indicates that the MakeConnection
> > protocol (operation and the use 2 of the MakeConnection URI template
in 
> > EndpointReferences) is required for messages sent from this endpoint.
> > This assertion has Message Policy Subject [WS-PolicyAttachment].
> > PaulF:
> > I think we can begin an electronic ballot for the rm and rmp
spec
> > <anish>
> > why do we need to change the policy subject?
> > <Dug>
> > I did that
> > <anish>
> > it can still be endpoint subject
> > <Dug>
> > hmm, ok say it can be either
> > <anish>
> > but the definition of the assertion only applies to out messages
> > <Dug>
> > The MakeConnection policy assertion indicates that the MakeConnection
> > protocol (operation and the use 2 of the MakeConnection URI template
in 
> > EndpointReferences) is required for messages sent from this endpoint.
> > *Resolution: *electronic ballot will be started for rm and rmp
without 
> > objection
> > <Paul Fremantle>
> > +1
> > <Dug>
> > The MakeConnection policy assertion indicates that the MakeConnection
> > protocol (operation and the use /of the MakeConnection URI template
in 
> > EndpointReferences) is required for messages sent from this endpoint.
> > This assertion has Endpoint Policy Subject [WS-PolicyAttachment].
> > <anish>
> > +1
> > <chris>
> > +1
> >  
> > Dug's text above is [2]
> > <anish>
> > just in time!
> > *Resolution: *motion [2] passes without objection
> > Paulf:
> > then it looks like we will proceed on an electronic ballot on
all three 
> > specs.
> > <Colleen>
> > +1 to the thanks to chairs and editors
> > <Mr. Goodner>
> > +1
> > <Paul Fremantle>
> > phew
> >  
> > Adjourned 17:31EST
> > <Paul Fremantle>
> > that was close
> > <anish>
> > good job paul
> > <Dug>
> > excitement right up to the end!
> > <Paul Fremantle>
> > thanks anish
> > <Paul Fremantle>
> > i'm pleased we resolved it
> > 
> > [End of Minutes]
> > Formatted on 2007-03-01 at 18:52:50 GMT-5
> > 
> > ------------------------------------------------------------------------
> > Minutes formatted by Schreiber, a collection of XSLT stylesheets
by Bob 
> > Freund modeled after David Booth's scribe
> > 
> > ------------------------------------------------------------------------
> > 
> > 
> >       Schreiber diagnostics output
> > 
> > [Delete this section before publishing the minutes]
> > 
> > citation-detection-scribed: Line 335: Check for possible unrecognized
> > nick 'Adjourned 17'
> > 
> > statistics: Schreiber found 202 input lines
> > 
> > edits: Schreiber found the following text-edit commands:
> > 
> > edits: Line 13: bob: s/2007/2007-
> > 
> > edits: Line 37: Dug: s/saw/say/
> > 
> > edits: Line 95: bob: s/re-h/red-h
> > 
> > edits: Line 211: Gil: s/wsa:/wsam:/
> > 
> > edits: Line 239: bob: s/s,/d.
> > 
> > edits: Line 257: bob: s/test/text
> > 
> > edits: Line 309: bob: s/,/:
> > 
> > edits: Line 317: bob: s/2 //
> > 
> > command-scribe: Line 7: bob is a nick for Bob Freund who will
be named 
> > as scribe
> > 
> > command-scribe: Schreiber detected that this section was scribed
online
> > 
> > edit-substitute: command on line 13 succeeded, changed line 9
from 
> > '2007' to '2007-'
> > 
> > edit-delete: Line 13 was deleted
> > 
> > edit-substitute: command on line 37 succeeded, changed line 35
from 
> > 'saw' to 'say/'
> > 
> > edit-delete: Line 37 was deleted
> > 
> > edit-substitute: command on line 95 succeeded, changed line 93
from 
> > 're-h' to 'red-h'
> > 
> > edit-delete: Line 95 was deleted
> > 
> > citation-detection-irc1: Line 119: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 120: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 121: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 122: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 123: Check for possible unrecognized
nick 
> > '</wsa'
> > 
> > citation-detection-irc1: Line 124: Check for possible unrecognized
nick 
> > '</ws'
> > 
> > citation-detection-irc1: Line 125: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 126: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 127: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 128: Check for possible unrecognized
nick 
> > '</wsa'
> > 
> > citation-detection-irc1: Line 129: Check for possible unrecognized
nick 
> > '<wsmc'
> > 
> > citation-detection-irc1: Line 130: Check for possible unrecognized
nick 
> > '</ws'
> > 
> > citation-detection-irc1: Line 131: Check for possible unrecognized
nick 
> > '</wsp'
> > 
> > edit-substitute: command on line 239 succeeded, changed line
134 from 
> > 's,' to 'd.'
> > 
> > citation-detection-irc1: Line 137: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 138: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 139: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 140: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 141: Check for possible unrecognized
nick 
> > '</wsa'
> > 
> > citation-detection-irc1: Line 142: Check for possible unrecognized
nick 
> > '</ws'
> > 
> > citation-detection-irc1: Line 143: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 144: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 145: Check for possible unrecognized
nick 
> > '<wsmc'
> > 
> > citation-detection-irc1: Line 146: Check for possible unrecognized
nick 
> > '</ws'
> > 
> > citation-detection-irc1: Line 147: Check for possible unrecognized
nick 
> > '</wsp'
> > 
> > citation-detection-irc1: Line 178: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 179: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 180: Check
for possible unrecognized nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 181: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 182: Check for possible unrecognized
nick 
> > '</wsa'
> > 
> > citation-detection-irc1: Line 183: Check for possible unrecognized
nick 
> > '</ws'
> > 
> > citation-detection-irc1: Line 184: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 185: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 186: Check for possible unrecognized
nick 
> > '</ws'
> > 
> > citation-detection-irc1: Line 187: Check for possible unrecognized
nick 
> > '</wsp'
> > 
> > citation-detection-irc1: Line 192: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 193: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 194: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 195: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 196: Check for possible unrecognized
nick 
> > '</wsa'
> > 
> > citation-detection-irc1: Line 197: Check for possible unrecognized
nick 
> > '</ws'
> > 
> > citation-detection-irc1: Line 198: Check for possible unrecognized
nick 
> > '<wsp'
> > 
> > citation-detection-irc1: Line 199: Check for possible unrecognized
nick 
> > '<wsa'
> > 
> > citation-detection-irc1: Line 200: Check for possible unrecognized
nick 
> > '</ws'
> > 
> > citation-detection-irc1: Line 201: Check for possible unrecognized
nick 
> > '</wsp'
> > 
> > edit-substitute: command on line 211 succeeded, changed line
205 from 
> > 'wsa:' to 'wsam:/'
> > 
> > edit-delete: Line 211 was deleted
> > 
> > edit-delete: Line 239 was deleted
> > 
> > edit-substitute: command on line 257 succeeded, changed line
255 from 
> > 'test' to 'text'
> > 
> > edit-delete: Line 257 was deleted
> > 
> > edit-substitute: command on line 309 succeeded, changed line
307 from 
> > ',' to ':'
> > 
> > edit-delete: Line 309 was deleted
> > 
> > edit-substitute: command on line 317 succeeded, changed line
313 from '2 
> > ' to '/'
> > 
> > edit-delete: Line 317 was deleted
> > 
> > system: Transformer: SAXON SA 8.7.1
> > 
> > [End of Schreiber diagnostic output]
> > 
> 
> -- 
> Paul Fremantle
> VP/Technology and Partnerships, WSO2
> OASIS WS-RX TC Co-chair
> 
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
> (646) 290 8050
> 
> "Oxygenating the Web Service Platform", www.wso2.com
>