On Tuesday, September 16, 2003, at 03:59 PM, Sunil Kunisetty wrote:
>
> Doug,
>
> Doug Bunting wrote:
>
>> 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.
>
> How does this proposal change the "existing" persistence requirements?
> As far as I recollect, it supports the existing ones without any new
> requirements. Atleast my intent was not to jeopardize any existing
> ones
> or add new ones.
>> If someone asks for the status of a message that was successfully
>> passed on to the application layer or that expired and was purged,
>> at sometime in the past, how do we know the status of the request
>> without archiving beyond the current requirements of the
specification?
>
>>
>>
>> I am curious why the StatusResponse contains a Status that seems to
>> include error conditions. What rules decide whether a situation
>> should
>
> Are you referring to InvalidGroupId & InvalidSequenceNo? If so, they
> are not the cause of the original msg., but rather the Status request
> msg.
> itself. If a receiving RMP receives a Status request for a msg with a
> GroupId that was not never sent or was invalid, it will then send an
> InvalidGroupId 'status' response corresponding to the 'status' request
> and not the original request.
>
>>
>> result in a Fault versus a Status? The current proposal leans toward
>> Status handling without explanation.
>
> I didn't understand the above.
>
>>
>> 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?
>
> This is a generic problem in the sense that we will have the same
> problem
> if we want to piggy-back Acks on other Requests & Responses. We ran
> into
> similar cases when Jacques is trying to propose a solution for
> Response
> Ack. pattern,
>
>>
>> If multiple StatusRequest elements are contained in one message, must
>> all related StatusResponse elements be included in a single message
>> as well?
>
> We could go either way, but for protocol simplicity we should say yes.
>
>>
>>
>> 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.
>
> We should then come with recommendation and exclusion cases.
>
> -Sunil
>
>
>>
>>
>> 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
>
