!! IMPT: Technical issues as I go through action items... !!

[Doug Bunting <Doug.Bunting@Sun.COM>]

I should have mentioned, this question needs an immediate response since it 
is a clarification and, therefore, a minor technical concern we should have 
considered a bit ago.  The existing words do not explain the semantics 
sufficiently enough to give an interoperable meaning to the 
Response@replyPattern value except in a few restricted situations (and the 
specification does not currently enforce those restrictions).  I do not 
want to decide upon our answer while doing the CD vote!

On 29-Jul-04 14:32, 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
>