[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of 10/13 meeting
Prelim minutes are attached Please post corrections before monday morning. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Preliminary Minutes WSRX TC Teleconf
|
Preliminary Minutes WSRX TC Teleconf October 13, 2005 – Tom Rutt agreed to take the minutes. 1 Roll CallUnofficial, official role will be in in Kavi to replace this at final posting
Meeting is (Quorate) 2 Review and approve of Agenda1) Roll Call 2) Review and approval of the agenda Should we discuss issues i006, i008 and i021 today? 3) Approval of the Oct 06, 2005 meeting minutes 4) Administrative Issues a> Quick survey of freeconference.com usage b> Reminder of CD review deadline (9 AM Pacific, Oct 18th, 2005) 5) AI Review 6) New issues since last conf-call 7) Issue Discussion: a> Issue 10: Sequence port spanning b> Issue 37: WS-Addressing Endpoint redefined in WSRM c> Issue 41: Presence of NACK and ACK range in the same message d> Isssue 43: Why is wsa imported in the WSDL? e> Issue 38: 2396 is obsoleted by 3986 f> Issue 44: SequenceFault element refers to fault code rather g> Issue 42: Which version of WS-Addressing spec? 8) Any other business Umit: Discussion on delays for Kavi to send updates. Duane N: sometimes the delay can be up to a couple of hours. It depends on load. Umit: the problem is thinks are often late and not always in order. Pete W: I recommend to look at headers to see if internal hop delaying, if not send Concerns to support@open-oasis.org Doug Davis: could we move issue 10 to next week. No objection issue 10 removed. Anish: Issue 42 is on agenda, and there was discussion at f2f. I see two points of view: any version of ws addressing, vs one version for interoperability. I am not sure we have agreement yet. Sanjay: I was hoping for a concrete proposal. However we should put issue 42 to next meeting. No objection, issue 42 removed. Agenda approved with changes. 3 Approval of Oct 06 meeting minuteshttp://www.oasis-open.org/committees/download.php/14845/MinutesWSRX-100605.htm Tom Rutt moved, Paul C seconded to approve the face to face minutes § No objection, Face To Face Minutes Approved. 4 Administrative Issues4.1
a> Quick survey of freeconference.com usage
Sanjay asked about experiences with freeconference.com. Rebecca: was the echo coming from that provider? Sanjay; the intial echoes went away after 10 minutes. Bob F: I notice
they have been handing out Canadian telephone numbers, which can be charged as
an international call. I prefer a Bob F: last time they handed out a number regarded as Canadian. Paul F: lets book calls in advance without and if we get a Canadian number we can ask for sponsors. Sanjay: lets go ahead with freeconference.com reserving many weeks in advance., and if we get Canadian numbers we will ask for sponsor for that call. 4.2
b> Reminder of CD review deadline (9 AM Pacific, Oct 18th, 2005)
Kavi ballot will be out oct 20 at. 9 am. Comments need to be put in by Oct 18th. 5 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php #0012: Chair took an action item to get a ruling from Jamie on CVS repository usage. Owner: Paul Fremantle Status: Leave Open – Doug D: we are just using Kavi for now. Sanjay: should we keep open to make it work. Doug D: yes. Assigned: 2005-07-17 Due: --- #0031: Open two issues around cancel / fill proposal and use cases Owner: Stefan Batres Status: Leave Open Assigned: 2005-09-21 Due: 2005-09-29 #0033: Anish will propose text to clarify in the current document the protocol is at least once, and that the DAs are subservient to this protocol. Owner: Anish Karmarkar Status: closed Assigned: 2005-09-27 Due: --- #0034: Abbie to raise new issue to have state diagram in the spec. Owner: Abbie Barbir Status: Leave Open Assigned: 2005-09-27 Due: --- #0035: Chris F to Raise a new issue on whether text to resolve issue 9 is to be an assertion or parameter. Owner: Christopher Ferris Status: closed Assigned: 2005-09-27 Due: --- #0037: Tom R to submit a concrete proposal to resolve Issue 008 for discussion by the TC members on the email list. Owner: Tom Rutt Status: Closed, however there is still discussion on issue. Assigned: 2005-09-27 Due: --- #0039: Marc G will ensure that the issue list contains pointers to the minutes discussion which carried the resolution. Owner: Marc Goodner Status: Leave Open – Marc Will updated soon Assigned: 2005-09-27 Due: --- #0040: Ashok to write proposed clarification text on meaning of “observed” in this spec. Owner: Ashok Malhotra Status: Leave Open – Ashok: there is currently discussion on this. The question is whether we have differences from standard ws-policy. I will attempt to write a free standing semantics for this policy assertion before next meeting. Assigned: 2005-09-27 Due: --- #0041: Doug D will write new issue to characterize the piggybacking of acks when using an anonymous AcksTo Owner: Doug Davis Status: Leave Open Assigned: 2005-09-27 Due: --- #0043: Doug D to post alternative proposal, taking away the additional text in his original proposal on Issue 10. Owner: Doug Davis Status: closed, however discussions continue on list. Assigned: 2005-09-27 Due: --- #0048: Doug D to fix editorial error in lines 637 and 638 of spec. Owner: Doug Davis Status: closed Doug sent to the list. Assigned: 2005-10-12 Due: --- 6 New Issues since last con call6.1
Proposed-01
Proposed by Chris F. http://lists.oasis-open.org/archives/ws-rx/200510/msg00046.html Title: Presence of multiple <SequenceAcknowledgement> headers for same Sequence in the same message Description: Anish has a proposal[2] for resolving i041[1]. I think that his proposed resolution clears up the ambiguity of the co-occurance of a <Nack/> and an <AckRange> in the same <SeqAck>, and that makes the prose consistent with the schema which uses an xs:choice. However, reading the issue itself lead me to consider that the spec says nothing about the presence of multiple <SeqAck> header blocks that might share the same <Identifier> in a given message. Justification: I don't believe that it was never intended to permit multiple <SequenceAcknowledgement> elements belonging to the same sequence in a given message. Target: core Type: editorial? Proposal: Add the following language to the spec after line 340 (pdf wd 03)[3]: A message MUST NOT contain multiple <SequenceAcknowledgement> header blocks that share the same value for <Identifier>. Related issues: i041 [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/Re#i041 [2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00208.html [3] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-wd-03.pdf Agreed to accept this as a new TC issue. 7 Issue Discussion7.1
b> Issue 37: WS-Addressing Endpoint redefined in WSRM
Description Section 2.1 defines the term 'Endpoint'. This is the same definition used by WS-Addressing [1] in section 1. Instead of defining this term again in WSRM, just point to the ws-addr document.
Justification In the spirit of composability and defining something once and reusing it, it makes sense to just refer to the WS-Addressing definition. This also protects us from minor changes in definition in the ws-addr spec (which is not final yet).
Related Issues Origin Anish Karmarkar
Owner Anish Karmarkar Proposal 12005-09-21 Replace the current definition by a reference to the WS-Addr spec. Tom: do we reference the LC version. Anish: that is a separate issue, as long as we use the same reference everywhere. That is Issue 42. Sanjay: Is there a dependence on issue 42? Anish: the reference will automatically change. Jonathan: there is no formal definition of endpoint in wsa core. Paul C: there is a section on endpoint references in WSA. Anish: we have cut and paste from the introduction of ws addressing. I would like to replace that with the refierence. Paul C: Ws addressing does not seem to have a hyperlink location for each definition, in a summary of definitions. Jonathan: there is not a formal definition of endpoint in ws addressing. Why should we refer to the introduction? Sanjay:; should we ask ws addressing for a better definition of endpoint. Tom R: That might be difficult, given my experience with the WS addr group. Umit: they define endpoint reference, but do not actually define endpoint. Paul C: the problem we have is that there is no place to hyperlink into the ws addr spec. Why not repeat the text, but add ‘as defined in ws addressing” as a prefix. Sanjay: Should we leave this as an action to the TC to replace the definition as it changes. Chris F: do we really think the defn will change enough that it matters. I agree we go with Paul C proposal. Chris F: I move we do it now, insert the current text from ws addressing with “as defined in ws addressing” as a prefix phrase. Jonathan: I second Chris F. § No objections to closing issue 37 with proposal from Chris F. 7.2
c> Issue 41: Presence of NACK and ACK range in the same message
Description Page 15, lines 344-345 say :
"This element MUST NOT be present if <wsrm:Nack> is also present as a child of <wsrm:SequenceAcknowledgement>."
Given that there can be multiple SeqAck headers in a message, this is true only for the same header and not across headers.
Justification WSRM allows multiple SeqAck headers, therefore one can Nack sequence "A" in one header and Ack Sequence "B" in another header in the same message.
Related Issues Origin Anish Karmarkar
Owner Anish Karmarkar Proposal 12005-09-21 Replace the sentence in question with "... MUST NOT be present if a sibling <wsrm:Nack> element is also present ..." Anish moved to accept proposal to resolve issue 41, Tom Seconded. § No objections, issue 41 resolved with Anish proposal 7.3
New proposed issue 1
Proposal: Add the following language to the spec after line 340 (pdf wd 03) A message MUST NOT contain multiple <SequenceAcknowledgement> header blocks that share the same value for <Identifier>. Chris moved and Paul C seconded to close proposed issue 1 with Chris F proposal. § No objection motion passed to close issue 1 with Chris F proposal. Issues editor needs to log the new issue and then record its resolution. 7.4
d> Isssue 43: Why is wsa imported in the WSDL?
Description On page 49, lines 156-1358 in [1], there is a schema import of the wsa namespace in the wsdl:types section. Why is this needed?
Justification The wsa element/types are not used by the schema (embedded in the WSDL) or used in the definition of any of the message constructs. The only place it is used is for wsa:Action (as a WSDL 1.1 extensible attribute). To do that, it is not necessary to schema import the namespace.
Related Issues Origin Anish Karmarkar
Owner Anish Karmarkar Proposal 12005-09-21 Remove the xs:import that imports wsa namespace. Anish moved Chris F seconded to accept Anish proposal to close issue 43. § No objection , motion passed, close issue 43 with Anish proposal. 7.5
e> Issue 38: 2396 is obsoleted by 3986
Description There are several reference to RFC 2396. This RFC is obsoleted by RFC 3986.
Justification RFC 2396 is obsoleted by RFC 3986. Related Issues Origin Anish Karmarkar
Owner Anish Karmarkar Proposal 12005-09-21 Either replace 2396 with 3986 OR like WS-Addressing, move to IRIs (RFC 3987). Chris F: since we reference ws addreissing the acks to can be an IRI so we should go with 3987. Jonathan: in wsdl and ws addressing we determined it was not a global replace. Chris F: I am only talking about our acksTo epr. Jonathan: I proposed to those groups that we look at each use of URI and you can tell if it is a specific or general term. If you talk about a specific URI, like a predefined action value in the spec, but they are restricted to the URI type restriction. Sanjay: the proposal from Anish is global, not specific to AcksTo. Jonathan: in the text explaining a particular value, we could use the term URI, if that value is a URI. Doug B: or ref section can include both, and we go thru the spec to decide which reference appears in each place. Thus the resolution of this one could be to replace the current single reference to separate reference to both, then open up Jonathan’s concern as a new issue. I would appreciate Jonathan to let us know what was done in WS-addressing and WSDL> Paul C: ws addressing refers to IRI spec, which in turn references URI. Ws addressing should refer to both rfcs. I prefer we fix the spec to get rid of defunct reference, and open a new issue to ask whether any uri should be change to IRI and then reference 3987. Doug B: I like Paul C proposal better than my previous proposal. Anish: Namespace URI, Action URI, and wsrm Identifier are all URIs. The first two cases are URIs since we define them as such. Chris F suggested to replace reference to RFC2396 with RFC3986. Open AI to open issue to explore which of the uses of the term URI need to be replaced with IRI. Bob F: all machine generated refs are IRIs, but once we type a specific value into our doc it is no longer specifically an IRI. It is a simple task to sort them out. Paul C moved, Chris F seconded to close issue with proposal. to replace reference to RFC2396 with RFC3986,. and to Open AI to open issue to explore which of the uses of the term URI need to be replaced with IRI. § No objection , motion passes to close Issue 38. with Ø Action: Chris F to submit new proposed issue to explore to explore which of the uses of the term URI need to be replaced with IRI. 7.6
f> Issue 44: SequenceFault element refers to fault code rather than
fault [Subcode]
Description On page 27, line 745 at [1] refers to fault code rather than fault [Subcode].
Justification Fault codes are either Sender or Receiver which map to S11:Client or S11:Server for SOAP 1.1. The text in question is actually talking about the fault [Subcode]s that are defined subsequently.
Related Issues Origin Anish Karmarkar
Owner Anish Karmarkar Proposal 12005-09-21 Either: 1) refer to fault [Subcode] instead of fault code Or: 2) refer to fault [Subcode] instead of fault code and change the element from wsrm:SequenceFault/wsrm:FaultCode to wsrm:SequenceFault/wsrm:FaultSubcode to match the abstract property that is being conveyed. I prefer (2). Tom R: Is 2 just a name change? Anish: yes, but some implementations my use the current name. Paul C: where are you proposing to change in the current text? Marc G: Section 3.7 of the document referred to in the issue. Anish: that line introduces a set of sub sections using the term “fault code” but the subsections is for fault sub codes. Umit: the ones actually defined are subcodes, not the code. Eg 770, 780. Paul C: on 671 the code is sender or receiver. Is there any element to send the code (eg line 684) Anish: this section is about soap 1.1, which does not have subcodes. We talk about fault codes rather than subcodes. Paul C: I had no problem when I read this, and I prefer not to change the element name. I have not been convinced of a need to make this change. Anish: line 725 says fault code, and is mapped to subcode. Paul C: is that orthogonal to what you are proposing here. Anish: Proposal 1 fixes the text but does not change the schema. Paul C: I can accept option 1. Doug B: I am asking whether we have a motion, and whether we are talking about the element name of just the terminology. Anish: Proposal 1 clarifies and uses proper terminilogy in the text, but does not change the schema. Anish moves to close issue 44 by change sentence line 745 and 746 of WD 03 (9/19) to refer to fault [Subcode] instead of fault code , Paul C seconded. § No objection, issue 44 closed with Anish Proposal 1. 1 New BusinessMeeting adjourned at 5:25 PM Eastern Time. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]