OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Prelim minutes of 3/2 teleconf


The prelim minutes are attached.

Please post corrections to the list.

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Preliminary Minutes WSRM TC Conference Call – Mar 02, 2004

 

The meeting of the WSRM TC took place by teleconference 
Tuesday Feb 24 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)
 

0         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Discussion of New Orleans Meeting and Conference papers

4 Discussions of Issues

5 Discussion of Editorial Comments

6 Discussion of Document Progression

Agenda approved

1         Roll Call

Attendance:

First Name

Last Name

Email

Role

Company

Joseph

Chiusano

chiusano_joseph@bah.com

Member

Booz Allen Hamilton

Chris

Hipson

chris.hipson@bt.com

Member

BTplc

Jacques

Durand

jdurand@us.fujitsu.com

Member

Fujitsu

Kazunori

Iwasa

kiwasa@jp.fujitsu.com

Secretary

Fujitsu

Tom

Rutt

tom@coastin.com

TC Chair

Fujitsu

Jishnu

Mukerji

jishnu@hp.com

Member

Hewlett-Packard

Robert

Freund

bob.freund@hitachisoftware.com

Member

Hitachi

Eisaku

Nishiyama

nishiy_e@itg.hitachi.co.jp

Member

Hitachi

Nobuyuki

Yamamoto

no_yama@bisd.hitachi.co.jp

Member

Hitachi

Junichi

Tatemura

tatemura@ccrl.sj.nec.com

Member

NEC Corporation

Alan

Weissberger

ajwdct@technologist.com

Member

NEC Corporation

Mark

Peel

mpeel@novell.com

Member

Novell

Sunil

Kunisetty

Sunil.Kunisetty@oracle.com

Secretary

Oracle

jeff

mischkinsky

jeff.mischkinsky@oracle.com

Member

Oracle

marc

goodner

marc.andrue.goodner@sap.com

Secretary

SAP

Pete

Wenzel

pete@seebeyond.com

Member

SeeBeyond

Doug

Bunting

doug.bunting@Sun.com

Secretary

Sun Microsystems

Chi-Yuen

Ng

cyng@csis.hku.hk

Member

University of Hong Kong

 

 

 Meeting is quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.

 

Minues will serve to record issue resolutions.

2.1      Approval of previous meeting minutes

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5702/MinutesWSRMTC022404.htm 
 
Alan  moved to accept the Feb 24 minutes. Jishnu  seconded.
 
No opposition, 2/24  minutes approved.

 

3         Discussion of New Orleans Meeting and Conference

Tom stated he told the OASIS staff that we wanted to meet all day Wednesday, and Thursday morning for our F2F.  This has been verified.

 

Jacques believes one of the initial submitters should be on the panel.

 

Jacques will deal with this off line.

 

4         Discussion of Issues

Issues which were already resolved:

Old resolve issues: Rel 105, 106

On 2/17 we resolved Rel 102

Last week we resolved issues Rel 108, 115, 114, 116

 

Editors should update the status.

 

4.1      Issue 49 WSDL Annotation

.

 

Anish stated he wants

 

If we do accept this the expiry times, should be expressed in seconds.

 

Marc Goodner:  He sent an email which gave his position.  The function is outside wsrm, and should not be in our spec.  It should not be done as part of this TC.  Having it be optional does not solve the problem it claims to be solving.  He could accept some parameter definitions, but cannot accept the generic framework,  That topic will make our spec controversial.   Much more generic functionality than we should be defining.

 

Chris (BT):  His concern is we be clear about what we are buying into and why.

 

Jishnu, sent an email:

I think what would be acceptable is a position which goes something like: We use the proposed framework subject to the following:

 

1. The intended scope of use of this framework as an extension point in WSDL1.1 is constrained to be within the WS-RM spec. This will not be advertised in the WS-RM spec as a standalone framework for use in WSDL 1.1 in general.

 

2. When  WS-RM evolves to work with WSDL 2.0, assuming that in WSDL 2.0 a standard mechanism is provided for annotating WSDL with properties/policies, WS-RM in that version would use the mechanism provided in WSDL 2.0 instead of the stopgap framework that is being proposed for WSDL 1.1.

 

BTW, there are other candidate ways of doing this (e.g. resource properties in WSRF, or the Quality of Protection patterns as found in WS-Security - after all all that is being addressed is annotation about QoS properties/policies in the realm of Reliability), so we (HP) are not necessarily married to this one that is being proposed, but would be happy to have any one (including the one being proposed) that works in the interim until the underlying core standard like WSDL grows up to cover this space.

 

Jishnu.

 

Jeff: We fundamentally agree with Jishnu.  That is why we scoped it for WSDL 1.1 only.  WSDL 2 will not be a rec for over a year.  We do not want ws-policy to get in the way, until it is a real standards process.  We are the first ones to decide to address the interop issue, it is a requirement.

 

Anish: Reiterating: my developers are saying that wsdl needs to be able to determine what rm features are required or available for a service.  We need something like this for WSDL 1.1.  I would be happy if we could come up with another proposal with equivalent functionality.  I disagree with Marc.

 

Anish: with regards to politics: the authors of ws-policy is not putting a standard out there for people to use, but also are objecting to other approaches.

 

I want a standard way to represent this in wsdl 1.1.

 

Jacques: Anish would be happy for any other mechanism for wsdl 1.1.  Then full conformance to wsdl 2 feature is not required.  There was an earlier schema from sunil, proposed at the last f2f, which is an alternative to the f&P approach.  Whatever way we do it is good enough.  This could avoid others complaining about the f&p approach.

 

Anish: I prefer the f&P because it is similar to wsdl 2.0.  This will allow easier migration when moving reliability to wsdl 2.0. 

 

Jeff: the reason to change the proposal from the earlier one is that we feel the new way is better.

 

Doug: one of the push backs on the original sunil proposal was that is was not aligned with the expected view of the future way to do this.  On the question of whether we are providing a generic infrastructure, then sometime later we could publish is as a separate thing.  This is a packaging issue, rather than addressing our problem at this time.

 

Jishnu: we are opposed to this TC publishing this as a conformance point outside WSRM.

 

Doug: that packaging issue is fundamental to now.

 

WS-standards.org is the namespace that they used on the generic proposal.  This is a namespace which is owned by Oracle.

 

Jishnu: I have to think about the namespace issue.

 

Anish: would it be possible to have the namespace to call Blah for now.

 

Jishnu: I have to think about this.

 

We have to decide this by next week.

 

Opposed to seeing this proposal getting into this spec.

Marc Goodner,

 

Keep it open, do more discussion, get down to specifics of words to get into document.

 

Jeff: would people accept it being put in today. Is the namespace the main concern of people.

 

Jacques: I need time to think about it.  I would prefer a namespace that is our own rather than the f&P.

 

Anish: I would like to suggest that people who think the namespace is a big issue,

 

I would be more than happy to change to another namespace.

 

Keep to the main group list.

 

4.2      Rel 117 Soap fault for missing reliability features in request

 

I propose we close this by adding the following to the paragraph on Soap Faults:

“For a WSDL request/response operation request, if the receiver does not want to invoke the service since a required ws-reliabiliy feature is not requested, then it MUST generate a soap server fault.  In this case, the fault detail SHOULD indicate that a required reliability feature was not requested.”

 

Sunil: Why not make this work in all cases.

 

Doug: what about the other modes we have.  The original sender may poll to get the same information.   

 

We should not say anything, and leave it to the implementation.  This specification should not mandate any mechanism to assert this.

 

Jacques I tend to agree on this, the only contract that the receiver has knowledge, is what is being transmitted through the message header.  The design of this spec did not require pre existing agreements, all was thru the message headers.

 

Close with no changes.

 

Sunil moved to close with no change to spec, Alan seconded.

 

No opposition, close issue no change.

 

4.3      Rel 118 Clarification Issue on Service enforcement of agreement

 

 

Sunil moved to close with no change, Bob F seconded.

 

No opposition, closed without change.

 

4.4      Rel 119 Sunil new Issue on Callback for Poll Request

 

  • New Issue
    From Sunil Kunisetty <Sunil.Kunisetty@oracle.com> on
    24 Feb 2004 00:50:10 -0000

New mail from Sunil:

If we do accept this, here are the  changes that we need to do.

 

   1. Add an optional replyTo attribute to PollRequest

   2. pg 6/line 177: Remove the replyTo attribute for Poll pattern in Request  (this may contradict to what I said in the editorial comments...)

   3. pg 7/line 212:Title of Example 3 would read "Acknowledgment Message embedded in HTTP Request"

   4. pg 7/line 213:HTTP Headers will have to change (should use POST)

   5. pg 8/line 239:Title of Example 4 would read "Fault  Message embedded in HTTP Request"

   6. pg 8/line 240:HTTP Headers will have to change (should use POST)

   7. pg 11/lines 334-339 should be reworded as follows:

 

          We say that Polling RM-Reply pattern is used if a second underlying request is issued to the  receiver of a previous message, in order to obtain a RM-Reply. The RM-Reply can be either contained in the underlying response to this poll request or in a separate underlying request from the receiver to the sender. This poling pattern is generally expected to be used in situations where it is inappropriate for the sender of reliable messages to receive underlying protocol requests (behind the firewall cases) or to avoid resending bulk messages often.

 

   1. pg 15/Figure 3. The 3rd line should be titled "Underlying protocol Response/Request".

   2. pg 28/section 4.3

         1. Table 9: Add an optional attribute call replyTo of type anyURI

         2. We need to mention that RM-Reply MUST be contained in the underlying response of the Poll request if this attribute doesn't exist and should be sent  in an underlying request to the endpoint identified by this attribute if exists.

   3. And finally the schema has to reflect this  by adding an optional attribute to the PollRequest element.

 

 -Sunil

 

Sunil:

You send initial message, in the message you say poll reply pattern and you have a reply to.   We do not say the reply to MUST not exist for the poll pattern.

 

The reply to could be on the original request, which could be used for the poll pattern.

 

Tom: how do you distinguish two separate poll requests, each with their own callback.

 

Sunil: it is not important, and does not warrant an ID.

 

-------

Doug: I see Tom’s comment as an unnecessary optimization of the relationship between the initial poll request and poll response.  The system receiving the poll response is mainly interested in getting the actual information from the receiver.  However I do not see the use case for this.  I would be happier without it being present.

 

No opposition in principle.

 

Sunil moves to accept his proposal and to add the clarification below:  Seconded by

Jishu

Minor open issue to clarify that reply to is not allowed for a poll and response reply pattern request.

 

No opposition, accepted.

 

4.5      Soap 1 issue

We closed this issue, but where is the soap 1.2 compatible schema?

Mail from Sunil:

I was about to venture into the WS-RM schema for SOAP 1.2 and realized

 that the only difference would be the namespace for the SOAP Envelope

 and the mustUnderstand attributes.

 

 So having 2 different schemas/namespaces is causing me some goose bumps.

 

 I've to admit that I was the one who initially suggested to have 2 different

 schemas/namespaces for SOAP 1.1 and SOAP 1.2. However, at that time

 strict schema validation is critical (ofcourse even now its important) and there

 are Header elements such as Fault Header which is used only for SOAP 1.1.

 And now that we have many occurrences such as existence of groupMaxIdleDuration  and groupExpiryTime attributes and replyTo attribute for Response and Poll  pattern which cannot be validated with schema and only thru' specification, so  having both mustUnderstand attributes (one for soap11 and other for soap12) on HeaderBaseType doesn't look that bad either. We then have to say in our specification clearly that one of these attributes MUST appear with a fixed

 value '1'.

 

 2 different schema will result in more examples (we have 2 give at least one

 example with soap 1.2 envelope), more appendixes, more maintenance,

 however, much cleaner.

 

 So essentially I don't know which is lesser of the evils... I want to finalize this

 before I come up with SOAP 1.2 schema for WSRM.

 

 Thoughts???

 

 -Sunil

 

The soap must understand 1.0 and 1.2 attributes.

 

Others have proposed both envelopes in one schema.

 

Doug: we stated we could have two schemas referring to a common body.

 

Anish: this is difficult , it is easier with two schemas.

 

The text in the document could stay the same.

 

Could put clarification that all our examples are soap 1.1

 

5         Discussion of Editorial Comments.

Editorial Comments for Discussion

The first comment from above was resolved by having a new base type for response.

 

 

 

Tom asked if there is any opposition to the editorial issues above. There was no opposition, so Iwasa should incorporate the editorial concerns.

 

Regarding the proposal from Sunil:

 

Sunil stated the names are too generic.  The names were change from past documents.

 

The examples are in the default namespace, thus the prefix does not appear.  This will confuse people.

 

The point about FaultCode is that is more generic. 

 

Sunil moved to rename headers to be preceded with RM and attribute Fault as FaultCode,

 

No second.

 

Fails due to lack of second.

 

 

6         Timing of WS-Reliability progression

Timeline proposed at F2F meeting.

  1. Feb 10   Tuesday call, final editing instructions agreed.
  2. Feg 12 – Document posted for TC internal review.
  3. Feb 24 – TC review comments resolved, editing instructions produced.
  4. Feb 25  Frozen document completed, TC review begins.
  5. March 2 – CD 1 ballot closes
  6. March 5 – 30 day Review initiated
  7. April 5 – 30 Day public Review ends
  8. April 15, submit to oasis staff for member vote
  9. May 01– Membership two week review
  10. May 15  – start member two week vote
  11. May 30 - member vote concludes.  Earliest Oasis Standard.

 

 

Doug: any substantial changes cause another round thru the committee draft.

 

Alan agreed it is critical.

 

Iwasa: I could make a document available by the end of today.

 

Doug: I do not see the need to have two almost identical schemas in our base doc. Keep the second one by reference. Do not need to put either of them in doc.

 

1)      everyting in both schemas.

2)      One of them in

3)      Neither of them in

 

Jeff M: I basically agree with Doug, however the schemas a normative and have to be visible for voting.  If it is in a zip file to go along with document that makes sense.

 

Note the schema for 1.2 is available.

 

Jeff M: put neither schema in PDF file, put them both in a zip file.

 

Doug: I completely agree, a zip file with the two normative schemas and the base document in one zip file is how we should vote the spec.

 

Later we need to decide on the dereferencing.

 

Jishnu: I agree.

 

No disagreement.

 

Jeff moved to have the balloted spec be a zip file with the base doc and the two normative schemas.  No schema in the base pdf.  Doug seconded.

 

No opposition.

 

Sunil: what about my new issue to eliminate Response reply pattern.

 

Doug:It is up to the sender to ensure it gets the response.

 

Sunil: I propose to get rid of the Response reply pattern.

 

Doug: I fundamentally disagree with Sunil’s position.  There is a truth that the reliability protocol does not accomodated reliable delivery of the response.  This is made clear in the document.  But by taking it out, w are missing a requirement.

 

Tom: There is a use case for duplicate elimination on Request.

 

Iwasa will post the new draft by 3/3 morning US time.  Sunil will post the two final soap 1.1 and 1.2 schemas to the web.

 

Tom stated we should target a committee draft to be sent out for ballot at next week’s meeting.

 

Meeting adjourned at 7:04 PM EST.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]