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: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern


I believe John had a good point that, while it may not change the 
suggested text, is certainly an important part of your proposal.  If we 
were to accept this proposal and require it in all implementations (not 
something that is entirely clear in this proposal), we may be changing 
the persistence requirements.

I am curious why the StatusResponse contains a Status that seems to 
include error conditions.  What rules decide whether a situation should 
result in a Fault versus a Status?  The current proposal leans toward 
Status handling without explanation.

Other issues arise due to the bundling suggested below.  When one 
StatusRequest is invalid (should result in a Fault) but the bundled 
business Request (or additional StatusRequest) does not, what happens? 
If multiple StatusRequest elements are contained in one message, must 
all related StatusResponse elements be included in a single message as well?

The existing patterns are focused on RMP-level signals and this proposal 
puts handling the status requests at that level.  This leads to 
potential handling delays if too many requests are bundled together.  In 
turn, this proposal leads to additional cases in which the patterns 
cannot hold.

Many systems will impose security restrictions in the area of these 
requests.  Some will refuse to respond positively to any request; others 
will ignore requests not coming from the originator of the referenced 
message.  These and other common situations should be described below.

Finally a new (separable) issue, both this suggested Status text and the 
existing description of faultcode values defined in our specification 
are rather lax about qnames.  Restrictions such as requiring a value to 
be a qname should be clear in the text, not just indicated in the schema 
(not a problem below).  Any possible value examples and descriptions 
should use a fully qualified name.


On 16-Sep-03 12:51, Sunil Kunisetty wrote:

> John Fuller wrote:
>>While I suppose it would add a diagnostic benefit, it sort of directly
>>addresses the RMP
>>as opposed to the RMP just knowing how to manage messages and hand them
>  The above issue  while is  important is out-of-scope of this particular requirement/proposal.
>  "Message management" was/should-be handled in the persistence/DE/RM sections.
>>How long would you have to archive message information to know
>>when expired groups were purged?  Or does it not assume transient
>>that persist, but a daemon that would only respond with knowledge since
>>its startup?
>>On Tuesday, September 16, 2003, at 01:51 PM, Sunil Kunisetty wrote:
>>> All -
>>> I had an AI @ the last F2F for coming up with a proposal for POLL
>>> Mark/Doug:
>>> Could you create a Spec. Issue for Requirement Issues 3.6 & 3.7?
>>> <ProposalBegin/>
>>>  I'd like to propose to have 2 new Headers:
>>>     StatusRequest
>>>     StatusResponse
>>>  StatusRequest will be the Header used by the Sender to send a
>>>  inquiry to the Receiver. It will have 2 sub-elements. A mandatory
>>>  and an optional SequenceNo. The types for these are the same as the
>>>  in MessageHeader element.
>>>  StatusRequest
>>>      - GroupId  - Mid URI type - Mandatory
>>>      - SequenceNo - UnsignedLong - Optional
>>>  StatusRequest can be sent without a MessageHeader and hence can be
>>>  piggy-backed on another Request or can be batched with other status
>>>  StatusResponse Header will be used by a Receiver to send the status
>>>  to Sender. It will have the following sub-elements:
>>>        - RefToGroupId      -  mid URI type - Mandatory
>>>        - RefToSequenceNo - unsigned long  - Optional
>>>        - Status                    - QNAME        - Mandatory
>>>  Possible Status Values are:
>>>        - InvalidGroupId -  When the GroupId is invalid or
>>>        - InvalidSequenceNo  - When the SequenceNo is invalid or
>>>        - MsgExpired - When the message was expired (based on
>>>        - MsgReceived - When the message was received and ack-ed by
>>>the RMP/
>>>  Since all our Header elements are extensible, Implementations can
>>>extend with a
>>>  new element called 'sub-status' and send more implementation
>>>specific details
>>>  if desired. But I prefer that Spec. level requirements for Status be
>>>  Multiple StatusResponse(s)  can be batched or can be piggy-backed on
>>>  We should be able to share the above Status values with Fault Codes.
>>>Note both
>>>  are QNAME types and hence shareable.
>>>  Error due to StatusRequest processing will result in a Fault with
>>>error code
>>>  InvalidStatusRequest.
>>>  <ProposalEnd/>
>>> Comments ???
>>> -Sunil
>>>To unsubscribe from this mailing list (and be removed from the roster
>>>of the OASIS TC), go to
>>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.

SunNetwork 2003 Conference and Pavilion
"An unparalleled event in network computing! Make the net work for you!"

WHEN:  September 16-18, 2003
WHERE: Moscone Center, San Francisco

For more information or to register for the conference, please visit:

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