[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] WS-RX draft minutes 2007-03-01 are attached
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]