Re: [wsrm] Contribution suggestions just uploaded

[Tom Rutt <tom@coastin.com>]

I cannot make a Friday meeting since I will be on a wilderness Lake 
Canoe camping.

Tom Rutt

Iwasa wrote:

>All,
>
>Since we are almost there, I would like to
>pursue possibility to meet 8/15 deadline
>for voting of the spec itself and its submission
>to OASIS. Would it be possible to realize that if:
>    - We agree the resolution for all remaining issues
>      at the telecon.(if any)
>    - Editors publish the final version of the spec
>      by the end of Thursday 8/12.
>    - Additional telecon on Friday afternoon/evening 8/13.
>       (This must have quorum.)
>       The possible agenda is:
>            - Check the last updates one by one.
>            - Voting for the spec to be CD
>            - Voting for OASIS submission
> ?
>
>Any thoughts?
>
>Thanks,
>
>Iwasa
>
>----- Original Message ----- 
>From: "Doug Bunting" <Doug.Bunting@Sun.COM>
>To: "wsrm" <wsrm@lists.oasis-open.org>
>Sent: Sunday, August 08, 2004 8:14 AM
>Subject: [wsrm] Contribution suggestions just uploaded
>
>
>  
>
>>The contribution I just uploaded[1,2,3] represents another improvement on
>>(but not the culmination of everything required to fix) the issues
>>discussed in my long-ago "Summary of WS-Reliability 1.01* issues discussed
>>over past week" email as well as the more recent "Detailed review of
>>Section 2-2.5, 5.2 and related definitions" and "about review of Section
>>2-2.5, 5.2".  We have made a lot of progress on improvements in this area
>>but a bit more remains.
>>
>>Note that the two footnotes I inserted are not intended for the final
>>document but simply explain a few deletions.  Those deletions also make
>>    
>>
>the
>  
>
>>footnotes much less sensible when not viewing the differences.
>>
>>Primary areas of concern addressed in this contribution include:
>>- The BP 1.0 WSDL / SOAP / HTTP restrictions inappropriately were applied
>>to the allowed abstract operations used at the producer / consumer level.
>>It does not make sense to apply HTTP and SOAP restrictions to the way in
>>which a SOAP processor (our RMP component) is invoked.  That represents an
>>unnecessary restriction reaching across 3 abstraction layers.
>>
>>- A few remaining clarity issues.  For example, while WSDL might be
>>    
>>
>written
>  
>
>>down to describe the RMP use of the underlying protocol, we have not done
>>so.  In spite of this lack, "WSDL" is occasionally used in ways that are
>>ambiguous.
>>
>>- A lack of support for the BP 1.0 restrictions presented in Section 6.
>>    
>>
>We
>  
>
>>need to generically describe various message exchanges as following the
>>patterns introduced in Section 2.3 ("SOAP one-way MEP" and "SOAP
>>request-response MEP") before the HTTP binding builds on those
>>    
>>
>assumptions.
>  
>
>>  A few more assumptions and implications needed to be written down.  This
>>was particularly troubling in light of the over-generality previously in
>>2.5.2 and 2.5.3.
>>
>>- Application of a SOAP One-way MEP restriction in 6.3 to the synchronous
>>Poll RM-Reply Pattern case.  Fixed by moving the appropriate restrictions
>>into 6.3.1 and 6.3.2.
>>
>>The specification still does a poor job describing when the Respond
>>operation is or is not supported.  Nor does it make clear the "meaning" of
>>a payload in a message containing only a Response header or that messages
>>with none of the Request, Response or PollRequest headers have no
>>significance under the WS-Reliability protocol.  Both classes of change
>>would likely be more significant than I undertook.  For example, it might
>>be reasonable to link the first Reliable Message "mentioned" in a Response
>>element with a payload in the same message but that would extend the rules
>>in 4.4 beyond the Response RM-Reply Pattern.  This contribution attempts
>>    
>>
>to
>  
>
>>illustrate the differences between the Producer / Consumer interface and
>>the SOAP message exchanges the RMPs implement but may not be "complete" in
>>this respect either.
>>
>>thanx,
>>doug
>>
>>[1]
>>
>>    
>>
>http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8586/WS-Reliability-2004-08-07-drb.sxw
>  
>
>>[2]
>>
>>    
>>
>http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8587/WS-Reliability-2004-08-07-drb.pdf
>  
>
>>[3]
>>
>>    
>>
>http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8588/WS-Reliability-2004-08-07-drb-diff.pdf
>  
>
>>To unsubscribe from this mailing list (and be removed from the roster of
>>    
>>
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>  
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>
>  
>

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