Re: [wsrm] Contribution suggestions just uploaded

[Doug Bunting <Doug.Bunting@Sun.COM>]

All,

As an editor, I am concerned about the lack of comments on the list from 
non-editors as well as the continued existence and new-found awareness of 
technical issues.  I am unable to pull together a document reflecting what 
I believe will be the outcome of these discussions and will let this email, 
Marks contribution and my contribution serve for now.

I see Iwasa's schedule as somewhat possible but doubtful due to the lack of 
comment on a number of questions.  Within the editing team, I had some 
questions about Mark's latest contribution we have not quite ironed out.  I 
have seen no comments on my earlier contribution (which happens to include 
a few additional editorial items but is mostly (minor or minor minor?) 
technical).

Additional questions for the group include:
- "If the specific RM Fault encountered was due to a problem with 
processing by the Receiving RMP, a SOAP server fault SHALL be returned." in 
4.5 (lines 1056-1057 in 1.082 "no changes" PDF) does not properly 
distinguish between the SOAP 1.1 and 1.2 cases.  Jacques has suggested "... 
a SOAP fault with faultcode "Server" (in SOAP 1.1) or "Receiver" (SOAP 1.2) 
SHALL ..."  Do we have other remaining cases where the 1.1 / 1.2 
distinction should be clarified?  Is this the correct fix for this case 
(for example, does "faultcode" cover both protocols)?

- Jacques believes our current text does not properly cover errors when 
invoking the Deliver operation.  I believe we have agreement within the 
editing team to add this case to Table 25 (as a 3rd case for 
MessageProcessingFailure) but have seen additional suggestions that go far 
beyond that.

- "A property is an assertion or constraint on a specific RM capability and 
its value(s) associated with WSDL elements." in B.3.3 (lines 1840-1841 in 
1.082 "no changes" PDF) remains murky.  Mark's original
question was "What's associated with WSDL elements here: a property, a
constraint, an RM capability, or its values?"  Mark has suggested removing 
"associated with WSDL elements" but we have not seen firm support for that 
change.  This has been mentioned a number of times on the TC list without 
comment.

Yes, I am probably leaving a few things out of interest beyond the editing 
team.  Sorry.

thanx,
	doug

On 10-Aug-04 13:11, Tom Rutt wrote:

> 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. 
>>
>>
>>  
>>
>