RE: syncReply element

[Martin W Sachs <mwsachs@us.ibm.com>]

Here is what Chris sent me to cover Tony's point (before Tony asked):

   Actually, this was discussed in Vancouver. Even in the event that the
   transport protocol does not support synchronous behaviour,
   such as SMTP, the value of syncReplyMode could still apply
   from the perspective of the actual construction of the message.

   A DeliveryChannel/Characteristics element that
   identifies a Transport that has no syncronous capabilities
   (such as SMTP) which also has a syncReplyMode attribute with a
   value other than "None" will respond with a message that
   contains the same content as if the Transport identified
   did support synchronous messaging (such as HTTP).


I will add the second paragraph (after some wordsmithing) to the section on
syncReplyMode.

Regards,
Marty
*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Tony Weida <TonyW@EDIFECS.COM> on 04/04/2001 11:32:33 AM

To:   christopher ferris <chris.ferris@east.sun.com>,
      ebxml-tp@lists.ebxml.org
cc:
Subject:  RE: syncReply element



Chris,

How exactly does the synchReplyMode affect message content?  Does it affect
signals as well as the (business) response?

In general, the combination of a synchReplyMode other than "none" with a
transport that doesn't support synchronous behavior seems confusing.
Perhaps the name of the attribute doesn't fully capture its intent.  In any
case, it would be great if you could come up with some explanatory text for
the spec.

Thanks,
Tony

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Wednesday, April 04, 2001 10:58 AM
> To: ebxml-tp@lists.ebxml.org
> Subject: Re: syncReply element
>
>
> Marty,
>
> Actually, this was discussed in Vancouver. Even in the event that the
> transport protocol does not support synchronous behaviour,
> such as SMTP, the value of syncReplyMode could still apply
> from the perspective of the actual construction of the message.
>
> A DeliveryChannel/Characteristics element that
> identifies a Transport that has no syncronous capabilities
> (such as SMTP) which also has a syncReplyMode attribute with a
> value other than "None" will respond with a message that
> contains the same content as if the Transport identified
> did support synchronous messaging (such as HTTP).
>
> Cheers,
>
> Chris
>
> Martin W Sachs wrote:
> >
> > I have appended an email from Chris containing the changes
> for synchronous
> > replies.  Please review and comment.  Please give this
> review priority
> > since we are running out of time to complete the next version.
> >
> > Chris, I have a couple of questions:
> >
> >    What if that delivery channel is pointing to a transport
> that has no
> >    synchronous reply capability?  Would you agree to a
> "SHALL" somewhere
> >    under the transport or transport protocol element
> stating: "If the value
> >    of the syncReplyMode attribute of the Characteristics
> element is other
> >    than "none", a transport protocol that supports
> synchronous relies (e.g.
> >    HTTP) SHALL be specfied."
> >
> >    The last paragraph of the text suggests a dependence on
> ebXML messaging.
> >    I would like to rephrase it.  Would you buy ths:
> >
> >      The ebXML Message Service's syncReply attribute is set
> to a value of
> >      "true" whenever the syncReplyMode attribute has a
> value other than
> >      "None".
> >
> > Regards,
> > Marty
> >
> **************************************************************
> ***********************
> >
> > Martin W. Sachs
> > IBM T. J. Watson Research Center
> > P. O. B. 704
> > Yorktown Hts, NY 10598
> > 914-784-7287;  IBM tie line 863-7287
> > Notes address:  Martin W Sachs/Watson/IBM
> > Internet address:  mwsachs @ us.ibm.com
> >
> **************************************************************
> ***********************
> > ---------------------- Forwarded by Martin W
> Sachs/Watson/IBM on 04/04/2001
> > 10:35 AM ---------------------------
> >
> > christopher ferris <chris.ferris@east.sun.com> on
> 04/03/2001 06:06:48 PM
> >
> > To:   Martin W Sachs/Watson/IBM@IBMUS
> > cc:   Chris Ferris <cferris@xroads.East.Sun.COM>
> > Subject:  Re: versioning the instance documents
> >
> > Marty,
> >
> > Yes, that's what I have. I hope to finish the xsd/dtd and samples
> > shortly. I just got the ftp accounts settled, so I'll also
> > post the XSD, DTD and samples to the web.
> >
> > Fot purposes of validation, this is necessary so that we
> > don't need to distribute the XSD or DTD, but can reference it
> > from a well known location (ebxml.org).
> >
> > I've also got the syncReply covered (attached .doc). Despite
> > our discussion last week where we concluded that placing it on both
> > the sending/receiving protocol element, I am now of the belief
> > that DeliveryChannel (as was the previous discussion... see Prasad's
> > various postings) is the correct place for this.
> >
> > As for Packaging, I'm having trouble still. My thoughts on this
> > topic will follow.
> >
> > Cheers,
> >
> > Chris
> >
> > Martin W Sachs wrote:
> > >
> > > Chris,
> > >
> > > It's all pencilled in.
> > >
> > > I added the attribute as the first attribute in CPP and
> the second one
> > > (i.e. right after id) in CPA.  It's probably a good idea
> to put it into
> > the
> > > DTD and XSD in the same place.  Or, if you already put
> into the XSD and
> > DTD
> > > differently, let me know and I will make the text and
> examples match (at
> > > the moment it only requires a pencil eraser to fix it).
> > >
> > > Regards,
> > > Marty
> > >
> > >
> >
> **************************************************************
> ***********************
> >
> > >
> > > Martin W. Sachs
> > > IBM T. J. Watson Research Center
> > > P. O. B. 704
> > > Yorktown Hts, NY 10598
> > > 914-784-7287;  IBM tie line 863-7287
> > > Notes address:  Martin W Sachs/Watson/IBM
> > > Internet address:  mwsachs @ us.ibm.com
> > >
> >
> **************************************************************
> ***********************
> > (See attached file: Characteristics element.doc)
> > (See attached file: chris.ferris.vcf)
> >
> >
> --------------------------------------------------------------
> --------------------------------------
> >                                   Name: Characteristics element.doc
> >    Characteristics element.doc    Type: Microsoft Word
> Document (application/msword)
> >                               Encoding: base64
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org
>

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org