RE: [wsrm] Comments on WS-Reliability CD 0.992

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Title: Message

So the following would be made explicitly illegal (instead of possibly just rather tricky to implement)

 

An existing (proprietary) reliable messaging system spans a number of systems. The applications using that system prefer to handle messages as entire SOAP envelopes, with application- or enterprise-specific headers perhaps. The RMS can handle SOAP envelopes as opaque content with no trouble, putting its own "headers" around them.

 

It is desired to have access in and out of the RMS from/to WS-Reliability-capable web-service applications/clients. Conceptually this should be possible, since the capabilities, guarantees and basic mechanisms of WS-Reliability and the RMS are the same.

 

One solution would be to have a WS-Reliability:RMS gateway that converted the WS-Reliability headers to and from their RMS equivalents. The naughty way of doing this is to go for those headers by type and not require or want any particular actor field. The "correct" way to do it would seem to be ask for the WS-Rel headers to be targetted on the gateway as a SOAP intermediary.

 

The proposal would seem to insist only the naughty approach is allowed. It can probably be justified as treating the whole RMS system as the WS-Rel user.

 

Peter

 

 

-----Original Message-----
From: Alan Weissberger [mailto:ajwdct@technologist.com]
Sent: 20 April 2004 00:00
To: Pete Wenzel; wsrm@lists.oasis-open.org
Subject: Re: [wsrm] Comments on WS-Reliability CD 0.992

I agree with Pete about explicitly forbidding an intermediary from tampering with WS Reliability headers.  In particular we need to prevent " man in the middle"  attacks.

No problem with passive monitoring of WS Reliability messages for accounting purposes

 

alan
----- Original Message -----
From: Pete Wenzel <PETE@SEEBEYOND.COM>
Date: Mon, 19 Apr 2004 13:07:07 -0700
To: wsrm@lists.oasis-open.org
Subject: [wsrm] Comments on WS-Reliability CD 0.992

> Here is my laundry list of things to fix in CD-0.992; most are
> editorial in nature.
>
>
> Line 98: Says "This specification addresses end-to-end reliability,
> and is not concerned with intermediaries." However, there is nothing to
> prevent someone targeting Reliability headers to "next" role/actor.
> This case should be explicitly forbidden, rather than left undefined.
>
> Lines 129, 1620: Reuse of "wsrm" prefix for different namespaces
> is confusing. Choose a different one for the feature namespace in
> the appendix.
>
> Line 134: Change
> "This specification defines reliable messaging protocol embedded in
> the SOAP Header."
> to
&g t; "This specification defines reliable messaging protocol features,
> expressed as extension header blocks embedded in the SOAP Header."
>
> 140 Use official name of the standard. Its title must be "WS-Security
> 2004", not just "WS-Security", to avoid confusion with prior incarnations.
> Remove the last sentence of this paragraph, which is already obsolete.
>
> Also Line 1581, reference should be:
> [WSS] "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)".
> Available at
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
>
> Section 1.5: Examples are placed in an awkward location. Should appear
> after the protocol & features are described. Suggest moving them to a
> non-normative appendix.
>
> Line 279: Change
> "A module capable of processing and enforcing Reliable Messaging as
> de scribed in this specification."
> to
> "A SOAP Processor capable of processing Reliable Messaging SOAP
> header blocks."
>
> Line 281, 317 (and throughout document): Prefer the more grammatical forms
> "Sending RMP"/"Receiving RMP" rather than "Sender RMP" and "Receiver RMP".
> Also replace instances where just "sender"/"receiver" are used, to be
> more specific that we are referring to a sending or receiving RMP.
>
> 569: Sequence Number is not a Feature; it is simply a mechanism used to
> implement Guaranteed Message Ordering. Should not be given equal status
> to the other 3 features.
>
> 1025-1030: Example in which SOAP Fault may also convey an RM
> Acknowledgment requires a confusing or impossible processing order.
> (Process RM headers, remember that an Ack needs to be sent, continue
> with header processing and SOAP Body validation and finally "applic ation
> processing space outside the realm of the receiving RMP".) How does
> the RMP know when all processing has been completed, then intercept a
> possible SOAP Fault in order to attach its Ack?
>
> 1990: Remove appendix if there is nothing to say here; the sole item
> listed is already done (Appendix A).
>
> The specification contains no reference to the schemas. They should
> be listed in the normative appendix, and introduced at an appropriate
> location in the text, perhaps at the beginning of Section 4.
>
>
> 269: Remove line break in the middle of "response".
> 501: "the Sender RMP notifies a delivery failure"
> should be
> "the Sending RMP is notified of a delivery failure".
> 522: "an" should be "a".
> 526: "nor to notify failure on the sender side" should be "nor to notify
> the RMP Sender of the failure".
> 527: "it's" shoul d be "its".
> Schemas: "it's" (in comment blocks) should be "its".
> 1036: Grammar.
> (The above list is not comprehensive; we could use a thorough proofreading
> pass to catch errors in grammar and punctuation.)
>
>
> --Pete
> Pete Wenzel
> Senior Architect, SeeBeyond
> Standards & Product Strategy
> +1-626-471-6311 (US-Pacific)
>
> 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.
>

Alan Weissberger

DCT

2013 Acacia Ct

Santa Clara, CA 95050-3482

1 408 863 6042 voice

1 408 863 6099 fax

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.