Sunil,
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.
thanx,
doug
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
>>off.
>
>
> 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
>>services
>>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
>>>pattern.
>>>
>>> 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
>>>poll/status
>>> inquiry to the Receiver. It will have 2 sub-elements. A mandatory
>>>GroupId
>>> and an optional SequenceNo. The types for these are the same as the
>>>ones
>>> 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
>>>requests.
>>>
>>> StatusResponse Header will be used by a Receiver to send the status
>>>back
>>> 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
>>>un-recognized
>>> - InvalidSequenceNo - When the SequenceNo is invalid or
>>>un-recognized
>>> - MsgExpired - When the message was expired (based on
>>>ExpiryTime)
>>> - 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
>>>simple.
>>>
>>> Multiple StatusResponse(s) can be batched or can be piggy-backed on
>>>Response.
>>>
>>> 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
>>>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.
>
>
>
> 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:
http://www.sun.com/sunnetwork
