Re: [wsrm] Technical issues as I go through action items...

[Tom Rutt <tom@coastin.com>]

I guess the receiving RMP would put multiple groups with the same reply 
pattern in one response message.

That means if , say 3 groups used callback, while 2 groups used poll, 
the 3 groups could be returned
together in a callback response, while the othere 2 groups could be 
returned together in a poll response.

However, this needs to be clarified.  I see no reason to allow changing 
the reply pattern across
messages in a single group.  But this needs to be clarified as well.

We need to discuss this at the Tuesday meeting as a new technical issue, 
and, unless the fix is trivial, we may
have to defer the cd vote until Aug 10 if we do not have the complete 
solution in place by Tuesday.

Tom Rutt

Doug Bunting wrote:

> What restricts the content of a Response message (or element) to 
> information about a single group?
>
> On 30-Jul-04 16:55, Tom Rutt wrote:
>
>> I always thought that the reply pattern had to be the same for every 
>> message sent in the group.
>>
>> If it does not say that, then I agree we have a technical issue to 
>> resolve.
>>
>> What reason would there be to send a different reply pattern for two 
>> messages with the same group ID?
>>
>> Tom Rutt
>>
>> If we clarified that all messages in a group must have the same reply 
>> pattern value, this will simplify each
>> return of the response element being from a single reply pattern 
>> (i.e., single reply for response reply pattern,
>> and batch of callback responses, or a batch of poll responses.
>>
>> Doug Bunting wrote:
>>
>>> First, my  apologies that the speeded-up  schedule agreed to  on 
>>> Tuesday is
>>> not coming  true.  While  I strive  to meet your  wishes, I  am 
>>> (obviously)
>>> falling back to the previous publication schedule.
>>>
>>> As I finish  up on the action  items, I keep coming back  to section 
>>> 4.4.1,
>>> "Attribute: Response@replyPattern".  I am unsure  what it is trying 
>>> to say.
>>> Specific questions for the group:
>>>
>>> 1. This  attribute  value  is   difficult  to  choose  when  the  
>>> published
>>>    RM-Replies relate to messages  with varying RM-Reply Patterns.  
>>> Only for
>>>    an underlying response to a  message with the Response RM-Reply 
>>> Pattern,
>>>    is  the  choice clear.   For  the  other  RM-Reply Patterns,  
>>> which  may
>>>    "bundle" information  about multiple Reliable Messages,  how 
>>> should this
>>>    value be chosen?   As one possibility, must all  described 
>>> messages have
>>>    arrived using the same RM-Reply Pattern (seems a bit restrictive)?
>>>
>>>    I note that  the ReplyPattern agreement item has  message scope, 
>>> meaning
>>>    it may change "randomly" even within a group.
>>>
>>>    A  potential confusion may  have existed  between the  
>>> implied(??) reply
>>>    pattern when responding to a PollRequest versus the reply pattern 
>>> of the
>>>    queried  Reliable Message(s).  This  case is  already covered  
>>> since the
>>>    Response@replyPattern value  clearly refers to the reply  pattern 
>>> of the
>>>    Reliable Message and not the most recent incoming message.
>>>
>>>    The most  obvious problems  arise when responding  to a  "general 
>>> status
>>>    query" PollRequest asking about  Reliable Messages with varying 
>>> RM-Reply
>>>    Patterns but this is not  the only cause for confusion.  More 
>>> generally,
>>>    the  Receiving RMP  is allowed  to supply  information  about 
>>> additional
>>>    messages if it  so chooses.  (At least, no  current restrictions 
>>> prevent
>>>    this.)   For  example,  a  single Callback  publication  may  
>>> optionally
>>>    include  additional information  about Reliable  Messages  which 
>>> arrived
>>>    with  other RM-Reply  Patterns (and  which the  Receiving  RMP 
>>> "somehow"
>>>    knows  were  from  the  same  Sending  RMP).  A  single  
>>> response  to  a
>>>    PollRequest  may do  the  same,  regardless of  the  number of  
>>> RM-Reply
>>>    Patterns   relevant  to   the  Reliable   Messages  identified   
>>> in  the
>>>    PollRequest.   (This is  also  true  for the  underlying  
>>> response to  a
>>>    Response RM-Reply Pattern Reliable Message but the "primary" 
>>> message and
>>>    therefore  @replyPattern value  is  clear  in that  case  and 
>>> that  case
>>>    alone.)
>>>
>>> 2. The  restrictions identified in  the final  two bullets  prevent 
>>> sending
>>>    additional information  about other singleton  (no SequenceNum) 
>>> messages
>>>    when responding to a message received as part of a sequenced 
>>> group.  The
>>>    SequenceReplies element must  be first in this case  and only 
>>> additional
>>>    SequenceReplies elements are allowed  according to the 
>>> specification and
>>>    the schema.   In the opposite  case, a NonSequenceReply element  
>>> must be
>>>    first  and may  be followed  with additional  NonSequenceReply 
>>> and  / or
>>>    SequenceReplies elements  (though never mixed according  to our 
>>> schema).
>>>    Was this the intent?  Or, should the schema look more like the 
>>> following
>>>    DTD?
>>>
>>>    ( NonSequenceReply | SequenceReplies )+
>>>
>>>    rather than the current
>>>
>>>    ( NonSequenceReply*, SequenceReplies* )
>>>
>>>    Yes, the "1  or more" part is enforced only in  the specification 
>>> at the
>>>    moment...
>>>
>>> 3. If this is covered in an action item I missed, please let me know!
>>>
>>> thanx,
>>>     doug
>>>
>>>
>>> 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. 
>>>
>>>
>>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133