Technical issues as I go through action items...

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

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