OASIS ebXML Messaging Services TC

 View Only

Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

  • 1.  Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo

    Posted 08-08-2001 22:02
    David:
    
    I don't quite agree with you that syncReply must apply to all transfer
    between two parties or none.
    
    Section 7.5.11.1 syncReplyMode attribute in the CPP/A spec allows for 4
    possible values: signalsOnly, responseOnly, signalsAndResponse, none.
    
    It also states:
    
    The ebXML Message Service's syncReply attribute is set to a value of "true"
    whenever the 1190
    syncReplyMode attribute has a value other than "none". 1191
    
    If syncReplyMode is set to signalsOnly, for example, I think the response
    will have to be returned asynchronously.
    
    Regards,
    -Arvola
    
    -----Original Message-----
    From: David Fischer <david@drummondgroup.com>
    To: christopher ferris <chris.ferris@east.sun.com>
    Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
    Date: Tuesday, August 07, 2001 6:44 AM
    Subject: RE: T2 SyncReply and ReliableMessagingMethod in
    QualityOfServiceInfo
    
    
    How do you set SyncReply on a message-by-message basis?  If I understand you
    correctly, syncReply MUST apply to ALL transfers between two parties or to
    None -- must always be the same.  I think we may want a little more
    flexibility.
    We allow this flexibility in multi-hop, why not in single-hop?
    
    In EDIINT, syncReply was always default to True and we occasionally would
    change
    to False for very large files -- allowing the connection to close rather
    than
    wait (potentially hours) for a very large file to be decrypted or the MIC to
    be
    generated for a NRR.  (Instead of syncReply, EDIINT calls this parameter
    Receipt-Delivery-Option).  IMO, we need to allow for the unforeseen.
    
    In the case of ReliableMessagingMethod, I'm not even sure what this does or
    why
    we need it at all.  What does a value of "Transport" mean -- the spec
    doesn't
    say?  I assume it means just send the message and don't worry about RM since
    this hop can't handle it?  I think this will never be used but David seemed
    to
    think it was needed and I don't have any heartburn with that.  Since I this
    sits
    right next to SyncReply in the Ack, I included it in parameters which need
    to be
    allowed without an Ack.  Either way is fine with me.
    
    David.
    
    -----Original Message-----
    From: christopher ferris [mailto:chris.ferris@east.sun.com]
    Sent: Tuesday, August 07, 2001 5:58 AM
    To: David Fischer
    Cc: ebXML Msg
    Subject: Re: T2 SyncReply and ReliableMessagingMethod in
    QualityOfServiceInfo
    
    
    David,
    
    Where does this requirement come from? In the case of
    syncReply, the CPA is what determines this. In the absence
    of a CPA, then a virtual CPA applies.
    
    Cheers,
    
    Chris
    
    David Fischer wrote:
    >
    > There should be nothing in the Via which is not also in other headers.
    Via
    > should only be used for multi-hop intermediaries.  In the case of
    SyncReply,
    > there is no single-hop way of requesting SyncReply=true.
    >
    > Attributes SyncReply and ReliableMessagingMethod should also be in
    > QualityOfServiceInfo.  They should retain their current defaults.
    >
    > Regards,
    >
    > David Fischer
    > Drummond Group.
    >
    > ------------------------------------------------------------------
    > To unsubscribe from this elist send a message with the single word
    > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
    
    
    ------------------------------------------------------------------
    To unsubscribe from this elist send a message with the single word
    "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org