ebxml-tp message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: Yet more issues to resolve


Sounds fine to me also.

/Stefano

» -----Original Message-----
» From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» Sent: Friday, January 05, 2001 8:32 PM
» To: Burdett, David
» Cc: Doug Bunting; 'Prasad Yendluri'; 'Stefano POGLIANI';
» ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
» Subject: RE: Yet more issues to resolve
»
»
»
» David,
»
» That sounds fine.
»
» 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
» ******************************************************************
» *******************
»
»
»
» "Burdett, David" <david.burdett@commerceone.com> on 01/05/2001 02:28:32 PM
»
» To:   Martin W Sachs/Watson/IBM@IBMUS
» cc:   Doug Bunting <Doug@ariba.com>, "'Prasad Yendluri'"
»       <pyendluri@webmethods.com>, "'Stefano POGLIANI'"
»       <stefano.pogliani@sun.com>, ebxml-transport@lists.ebxml.org,
»       ebxml-tp@lists.ebxml.org
» Subject:  RE: Yet more issues to resolve
»
»
»
» Marty
»
» I can't think of anything in the spec that is tied to a
» particular instance
» of a MSH. On signatures, that hasn't been speced yet (Chris??) however I
» anticipate that as a Routing Header can change if you are using a
» different
» channel, then you would need to regenerate any signature over the routing
» header.
»
» I also agree with clarifying the spec on retries over different channels
» although I would not want to make it as strong as a recommendation. So how
» about adding the following to section to the end of ssection 10.2.1.3 on
» resending messages ...
»
» >>>As an implementation decision, an implementer of a MSH might want to
» consider the enabling of resends of data using different transport
» protocols
» and perhaps using different instances of a MSH. This is likely to require
» that all the MSHs share the same persistent storage so that duplicate
» messages can be detected correctly.
» <<<
»
» -----Original Message-----
» From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» Sent: Friday, January 05, 2001 9:55 AM
» To: Burdett, David
» Cc: Doug Bunting; 'Prasad Yendluri'; 'Stefano POGLIANI';
» ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
» Subject: RE: Yet more issues to resolve
»
»
»
» David,
»
»
» My replies embedded below.
»
» 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
» ******************************************************************
» **********
»
» *********
»
»
»
» "Burdett, David" <david.burdett@commerceone.com> on 01/05/2001 12:12:20 PM
»
» To:   Martin W Sachs/Watson/IBM@IBMUS
» cc:   Doug Bunting <Doug@ariba.com>, "'Prasad Yendluri'"
»       <pyendluri@webmethods.com>, "'Stefano POGLIANI'"
»       <stefano.pogliani@sun.com>, ebxml-transport@lists.ebxml.org,
»       ebxml-tp@lists.ebxml.org
» Subject:  RE: Yet more issues to resolve
»
»
»
» Marty
»
» I honestly don't think that it violates anything in the spec since
» resending
» over a different transport has long been thought of as a good
» idea. I agree
» though that an implementation decision could be to design/implement a
» solution that has different MSH for each transport protocol.
»
» MWS:  If an implementation has a different instance of the MSH for each
» transport protocol, those instances have to share whatever information is
» in retries of messages.  For example, if a message was originally
» sent over
» transport A and then is re-sent over transport B, transport B must be able
» to recognize it as a duplicate. As long as there is nothing in the
» messaging
» spec that might prevent that sharing, then I guess that there is
» no problem
» with retry over a different transport protocol.  It all boils down to
» whether
» there is anything in the spec that is tied to a specific instance of the
» MSH.
» What about signing of headers?
»
»
» In my view, it is more of a CPA/CPP issue, in that if you define alternate
» transport channels for a particular message in a business
» process, then you
» need to make sure that you have the technology to support the alternative
» transport within the same message. If this is not the case then don't put
» it
» in the CPP/CPA.
»
» MWS:  Something tells me that whether or not multiple instances of the MSH
» are
» capable of retrying (and in particular detecting duplicates) when
» the retry
» goes over a different transport is buried deep in the
» implementation and it
» would be not easy for someone writing a CPP or CPA to make the
» determination.
» This might be a case for another non-normative statement:  If an
» implementation
» has multiple instances of the MSH within a single system, it is
» recommended
» that
» the implementation permit a message to be retried over a
» different instance
» of
» the MSH.
»
» MWS:  CPP/CPA certainly allows defining multiple delivery channels.  IBM's
» tpaML
» allows duplicate checking to be specified at the document-exchange level
» (i.e.
» the messaging level).  However we never attempted to define our own
» messaging
» protocol, so we did't think about most of the things we are
» discussing now.
» Perhaps someone :-) who is closely associated with both TP and TRP could
» provide
» the necessary input about retries to the TP definition.
»
» Another way you might be able to do it is by sending the same
» payload again
» using a different messageId.
»
» MWS:  I would certainly expect this to be the case for retries for
» business-level
» conditions.  It may or may not be suitable for retries within the MSH for
» conditions detected by the MSH.
»
» Thoughts?
»
» David
»
» -----Original Message-----
» From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» Sent: Friday, January 05, 2001 7:25 AM
» To: Burdett, David
» Cc: Doug Bunting; 'Prasad Yendluri'; 'Stefano POGLIANI';
» ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
» Subject: RE: Yet more issues to resolve
»
»
»
» David,
»
» >>>It can't always be "exactly  the same stream of bytes on the
» wire since,
» if you resend a message using a  different transport protocol, then you
» need to use a different Routing Header  with different URIs.<<<
»
» MWS:  We need to be very careful about resending a message using a
» different transport protocol.  A different transport
» protocol may mean a different physical port on the sending machine and
» possibly a different instance of the MSH.  So I agree that in
» this case, it
» won't be exactly the same stream of bytes.  But if it is a different
» instance of the MSH, does this violate any assumptions that are behind the
» specification?  Do we have to beef up the specification to ensure that
» multiple instances of the MSH can be involved in the protocol for the same
» message?
»
»
» 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
» ******************************************************************
» **********
»
»
» *********
»
»
»
» "Burdett, David" <david.burdett@commerceone.com> on 01/05/2001 02:47:07 AM
»
» To:   Doug Bunting <Doug@ariba.com>, "'Prasad Yendluri'"
»       <pyendluri@webmethods.com>
» cc:   "'Stefano POGLIANI'" <stefano.pogliani@sun.com>, Martin W
»       Sachs/Watson/IBM@IBMUS, ebxml-transport@lists.ebxml.org,
»       ebxml-tp@lists.ebxml.org
» Subject:  RE: Yet more issues to resolve
»
»
»
»
» Doug
»
» See  comments below.
»
» David
» -----Original Message-----
» From: Doug Bunting  [mailto:Doug@ariba.com]
» Sent: Thursday, January 04, 2001 11:29  AM
» To: Burdett, David; 'Prasad Yendluri'
» Cc: 'Stefano  POGLIANI'; Martin W Sachs; ebxml-transport@lists.ebxml.org;
» ebxml-tp@lists.ebxml.org
» Subject: RE: Yet more issues to  resolve
»
»
» Two additional comments related to persistent storage with
» respect  only to
» implementing Reliable Messaging.  Again, legal or business  reasons for
» additional storage must be considered and described separately, I  think
» that's the purpose of the persistDuration parameter.
»
»    Persistent storage at the receiving side MUST (in RFC 2119
»    terms) include both the messageID value and the corresponding
»    intermediate ACK (if any).  The exact same answer should go back to the
»    sender no matter how many times they send a duplicate  message.
»
» >>>I agree, that MessageId needs to be  persisted. However persisting
» the intermediate ack is a function of the  sending process not the
» receiving process. See also section  10.2.1.2<<<
»
»    If it isn't  already clear in the specification (and, I don't think it
»    is), we should  make sure the messageID corresponds to a particular set
»    of bytes.  I  believe we've said that retries must use exactly the same
»    message as  before.  I don't think we've made "exactly" quite clear
»    enough.   Is it "semantically identical content" or "matching canonical
»    form" or  (my choice) "exactly the same stream of bytes on the wire"?
»
» >>>It can't always be "exactly  the same stream of bytes on the
» wire since,
» if you resend a message using a  different transport protocol, then you
» need to use a different Routing Header  with different URIs.<<<
»  We may  also want to describe a possible error (detected by the receiver)
» when  the checksum of the message doesn't match that (optionally) stored
» along  with a messageID.
» >>>One of the  problems of doing checksums, is that it has to be done over
» a canonical  version of the document. Sending the same bytes might result
» in a different  set of bytes being received, especially if you are using a
» transport such as  SMTP that can alter the message content. So I
» think that
» if this is important,  then you should use XML Dsig to make sure that the
» message is the same as  it includes transformations that allow a canonical
» form to be generated.  <<
»  I  definitely agree that the sender needs to persist the entire request
» until  it receives the intermediate or final acknowledgement. 
» The receiver
» should not be required to persist the request for reliable  messaging
» purposes, though they could.  (Of course, a receiver that is  forwarding
» the message in turn must persist the request as any other sender  would.
» Since we distinguish between the inbound and outbound MSH  instances at
» intermediate nodes, this might not need to be described in our
» specification.)  The intermediate choice of storing a hash or
» checksum would be OPTIONAL (also in RFC 2119 terms).
» >>>Please see  comments above, and the revised definition of
» PersistDuration<<<
»
» thanx,
»     doug
»
» -----Original Message-----
» From: Burdett, David  [mailto:david.burdett@commerceone.com]
» Sent: January 3, 2001  21:56
» To: 'Prasad Yendluri'
» Cc: 'Stefano POGLIANI'; Martin  W Sachs; ebxml-transport@lists.ebxml.org;
» ebxml-tp@lists.ebxml.org
» Subject: RE: Yet more issues to  resolve
»
»
» Prasad
»
» See  comments below.
»
» Regards
»
» David
» -----Original Message-----
» From: Prasad Yendluri  [mailto:pyendluri@webmethods.com]
» Sent: Wednesday, January 03,  2001 7:21 PM
» To: Burdett, David
» Cc: 'Stefano POGLIANI';  Martin W Sachs; ebxml-transport@lists.ebxml.org;
» ebxml-tp@lists.ebxml.org
» Subject: Re: Yet more issues to  resolve
»
» David,
»
» The description for the "persistDuration" parameter reads as follows:
» PersistDuration is the minimum length of time in days that  a Message that
» is sent reliably is kept in Persistent Storage by a MSH.  The value used
» for PersistDuration is an implementation decision although  it MUST be
» greater than the value of the TimeToLive parameter for any
» message that is
» sent.If a duplicate message (i.e. with the same MessageId ) is  received
» before the PersistDuration has passed, then the MSH that receives  it MUST
» process it as a duplicate message as described  in sections  10.2.1.3 and
» Error! Reference source not found..
»
» If a duplicate message is received after the PersistDuration has  passed,
» then although it may be treated as a duplicate, the sender must  realize
» that it will probably be treated by the MSH as if the message were  a new
» message that had not been received before.
» 1. If the purpose of this is to simply detect duplicates why require  the
» entire message to be stored? Isn't saving the value of the messageId
» enough?
» <DB>
» Yes, the MessageId is enough. It was not my  intention to REQUIRE that a
» whole message should be kept. Note that I did  not say that "
» PersistDuration is the minimum length of time in days that  a **complete**
» Message that is sent reliably **MUST be** kept in Persistent  Storage by a
» MSH. Also  lines 1213-1216 in Reliable messaging, that describe the
» behavior of a MSH  that receives a message, explicitly say ...
» >> 1)        If the message is not a duplicate then do the following:
»      a)        Save the MessageId of the received message in  persistent
» storage. As an implementation decision, the whole message  MAY be
» stored if
» there are other reasons for doing  so.<<
» Another factor is that, if you want to support a Message Status  Inquiry,
» then you will also need to record the time a message was
» received.  I agree
» though that the description of persist duration could be clarified  to
» indicate that only the MessageId needs to be saved.
» </DB>
»  If any, I would think it is  the sender MSH that needs to persist the
» message, so that a retry would a  simple retransmission.
» <DB>
» I  agree the sender MSH does need to persist the message. Line 1200 in the
» Reliable Messaging specification that is describing the behavior of a
» sender  of the message says ...
» >> 1)        Save the message in persistent storage (see section 10.1.1)<<
» However how long the sender saves the message for  is not relevant to
» Reliable Messaging. You need to know it for the receiver  since
» you need to
» know if you resend a message whether or not duplicate  filtering will work
» which it won't if the reciever has not persisted the  message. The same
» does not apply to the sender since the persisting of the  message only
» applies to resending.
» </DB>
»
» 2. Why the value limited to "days"?
» <DB>A good point. My original thinking  was that if the message is being
» placed in some type of persistent storage  such as a disk, then you
» probably would not want to clear it out too often.  So setting it to whole
» days makes it a simpler value than the years, months,  weeks, days, hours,
» minutes, millisecs?? that you might otherwise need.  Another
» approach is to
» specify a single integer and then put the units in  separately such as
» <persistDuration  units="seconds">20</persistDuration> in the CPA. Would
» that work  better?</DB>
»
» 3. The last paragraph seems to imply that sender and receiver could be in
» an inconsistent state without clear knowledge of, if retries on a message
» are still permitted or not. That is sender thinks retries are still
» permitted but, receiver does not know it is a re-send, as the message was
» deleted from the persistent store. If we got the Reliable Messaging
» specification right, this should never be the case. At least one of the
» parties should always know.  The receiver must always know if the
»  received
» message is duplicate or not, if the message was received once
» successfully, irrespective of, if the entire message is (still) persisted
» or  not (based on the MessageId alone). We should never retire the
» MessageId  either from sender/receiver (or intermediary)
» perspective. It is
» a GUID  isn't it?
» <DB>I agree that ideally the  Message Ids should never be "retired".
» However what I think you are  suggesting is that the MessageIds are
» **never** deleted by the receiver. I  honestly don't think this is
» practical, since if you want to forever to be  able to do a duplicate
» check: a) the MessageIds received have to be  immediately available in
» order to provide a rapid response to the duplicate  check, and b) this
» would imply ever increasing persistent storage which  would prove
» costly to
» maintain. This means that the recipient of a message  will have
» to, at some
» point, delete old message ids. The point is that the  sender needs to know
» whether or not duplicate filtering will work. By  specifying a
» persistDuration for received Message Ids, the Sender will  knowthat the
» duplicate filtering will work, especially if the persist  duration is
» significantly longer than any period of time over which a
» message might be
» resent. However the sender can never know EXACTLY when the  sender will
» delete a message id unless they do a query first.
»
» Perhaps it would be better if the last paragraph said ... "A MSH  SHOULD
» NOT resend a message to a receiver if the receiver has probably  deleted
» the message since the time indicated by PersistDuration has passed  since
» the sender first sent the message." You could even require that a  sender
» report a delivery failure if the time has  passed.
» </DB>
»
» 4. I think, how long a message should be persisted in the MSH should be
» based on acknowledgment and retries and associated timeout constraints of
» the business process choreography and not based on a separate parameter
» that  tells how long the message should be kept.  Any parameter that
» dictates how long a  message is persisted should probably be driven by
» legal requirements such as  non-repdudiation.
» <DB>There has been recent  discussion on this topic on the list. See the
» thread at ...
» http://lists.ebxml.org/archives/ebxml-transport/200012/msg00211.html
» I disagree  that basing persistence duration solely on acknowledgement and
» retries is  sufficient. This can work for a sender if there are
» no legal or
» other  reasons for saving the message. However it is insufficient for a
» receiver of a message.
»
» I completely agree though that the value set  on message persistence by a
» recipient of a message is governed by several  factors including:
» a) the need for a sender to know if reliable messaging  will work
» b) the requirements of a business process choreography
» c)  other needs such as legal requirements.
» This is why persistDuration is a  parameter that can only be set in the
» CPP/CPA (see the table at line 1482).  It can't be set in the header.
» Therefore persistDuration can be, as you  suggest, controlled by the needs
» of the business process as the CPA much of  the information in the CPA is
» controlled by business process needs. However,  the information
» still needs
» to be known by the MSH that is doing reliable  messaging and
» hence the need
» to include as a CPA parameter that is used by  the MSH.
» </DB>
»
» Regards, Prasad
»
» "Burdett, David" wrote:  Stefano
»
» Version 0.91 of the spec has the concept of a "persistDuration"  parameter
» that would be in the CPA/CPP that identifies the number of  days a message
» that is sent persistently should be kept by the  receiving MSH.
»
» The spec is not specific about how long messages that are sent are
» persisted. However this should be as I think you are saying, until the
» sender knows that the sent message has arrived since an  acknowledgement
» message has been returned.
»
» Does this make sense?
»
» David
»
» -----Original Message-----
» From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
» Sent: Wednesday, January 03, 2001 3:29 PM
» To: Martin W Sachs;  Burdett, David
» Cc: ebxml-transport@lists.ebxml.org;  ebxml-tp@lists.ebxml.org
» Subject: RE: Yet more issues to resolve
»
» Marty, David,
»
» a little clarification w.r.t. "I also don't like the idea of placing a
» restriction on the MSH to persist a message until the transaction is
» complete, ..."
»
» I think that an option would be to allow the MSH to be "controlled" by
» outside w.r.t. this part and by defining a "default behaviour". "Not
» saying
» anything" (as mentioned by Marty) would mean, IMHO, that the  "default
» behaviour" is to remove the message as soon as it reliably  reaches the
» target MSH.
» Giving the option to "control from  outside" would allow the layer between
» the MSH and the real  application to take care (if it will be
» capable) of a
» more  sophisticated behaviour.
»
» /Stefano
»
» » -----Original Message-----
» » From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» »  Sent: Saturday, December 30, 2000 2:23 AM
» » To: Burdett, David
» »  Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
» »  Subject: RE: Yet more issues to resolve
» »
» »
» »
» » David,
» »
» » The definition of persistDuration in your email looks OK.
» »
» » My point about decoupling persistence from reliable messaging  was
» » a CPA/CPP
» » point, not a MSH point.  I am simply  suggesting that two parties
» » might have
» » reasons to come to  agreement on persistence that have nothing
» to do with
» » the MSH in  addition to its use with RM.
» »
» » Regarding "I also don't like the  idea of placing a restriction on the
» MSH
» » to persist a message until  the transaction is complete, ..."  I don't
» like
» » placing that  restriction either.  I was asking for the opposite - that
» the
» »  MSH specification should not say anything which either prescribes or
» »  suggests that a message can be deleted from the persistent store
» » as  soon as
» » it reliably reaches the destination MSH.  Earlier  versions of the RM
» » specification included such words.
» »
» »  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
» »  ******************************************************************
» »  *******************
» »
» »
» »
» » "Burdett, David"  <david.burdett@commerceone.com> on 12/27/2000 11:20:24
» AM
» »
» » To:   Martin W Sachs/Watson/IBM@IBMUS
» »  cc:   ebxml-transport@lists.ebxml.org, ebxml-tp@lists.ebxml.org
» » Subject:  RE: Yet more issues to resolve
» »
» »
» »
» » Marty
» »
» » In version 0.9a of the spec, a parameter called  "pesistDuration"
» » is defined
» » that is described as follows:
» »
» » "PersistDuration is the minimum length of time in days that a  Message
» that
» » is sent reliably is kept in Persistent Storage by a  MSH. The
» » value used for
» » PersistDuration is an implementation  decision although it MUST be
» greater
» » than the value of the  TimeToLive parameter for any message
» that is sent.
» »
» » If a  duplicate message (i.e. with the same MessageId) is
» received before
» »  the
» » PersistDuration has passed, then the MSH that receives it MUST  process
» it
» » as
» » a duplicate message as described in sections  10.2.1.1 and 10.2.1.2.
» »
» » If a duplicate message is received  after the PersistDuration
» has passed,
» » then although it may be  treated as a duplicate, the sender must realize
» » that
» » it will  probably be treated by the MSH as if the message were a
» » new message
» » that had not been received before."
» »
» » So as it stands, the  persistDuration only applies to Relilable
» Messaging
» » behavior which I  think is right. I know that there are other, e.g.
» legal,
» » reasons why  a messages might be persisted beyond this time.
» However from
» a
» » MSH  perspective, I think we can only specify the behavior of
» the MSH and
» »  nothing else.
» »
» » I also don't like the idea of placing a  restriction on the MSH to
» » persist a
» » message until the  transaction is complete, since the MSH will
» » probably need
» » to  be told by the application that the transaction is complete and it's
» »  possible that some backend systems will not be able to easily do this.
» »
» » Do you think the existing definition is OK?
» »
» » David
» »
» » -----Original Message-----
» » From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» »  Sent: Tuesday, December 19, 2000 9:56 AM
» » To: Christopher Ferris
» » Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
» »  Subject: Re: Yet more issues to resolve
» »
» »
» »
» » Chris,
» »
» » Regarding issue 19:  I agree that there should be nothing  in the TRP
» spec
» » about how long a message must be persisted since  higher layers are
» » involved.  Perhaps the messaging spec should  say that persistence must
» be
» » at least until the reliable messaging  procedure has been
» » completed for that
» » message  transmission.  I suggest a non-normative note explaining the
» »  issues.
» »
» » In my opinion, at the higher levels, persistence  should be at least
» until
» » the business transaction is  concluded.  Persistence beyond that
» » is probably
» » not a  matter that has to be agreed to.  It is probably an internal
» matter
» » for each party.
» »
» » If the persistence element will be in  your upcoming CPP/CPA DTD, please
» » supply some explanatory text with  it.  I suggest not coupling the
» » persistence element in the CPA  to reliable messaging.  While it is
» » essential to reliable  messaging, it is also something that might be
» needed
» » without ebXML  Reliable Messaging.  For example, if the parties use a
» »  transport that is reliable in and of itself, they would probably not
» want
» » to invoke ebXML Reliable Messaging on top of it but they might want  to
» » specify something about persistence.
» »
» » 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
» »  ******************************************************************
» »  **********
» »
» » *********
» »
» »
» »
» » Christopher  Ferris <chris.ferris@east.sun.com>@east.sun.com on
» 12/19/2000
» »  12:23:17 PM
» »
» » Sent by:  Chris.Ferris@east.sun.com
» »
» »
» » To:   ebxml-transport@lists.ebxml.org
» » cc:
» » Subject:  Re: Yet more issues to resolve
» »
» »
» »
» » Ian,
» »
» » Thanks for sending these out. Some comments below.
» »
» » Cheers,
» »
» » Chris
» » ian.c.jones@bt.com wrote:
» » >
» » > TR&P people,
» » >
» »  >         Sorry this is late -  the real world gets in the way
» » occasionally.
» » >
» » >  The following issues may now have been overtaken by events but
» » we  need to
» » at
» » > least acknowledge this so that I can get the  database of issue and
» » changes
» » > update by the New Year.
» » >
» » > ####
» » > Issue 15
» » > Title - RM Info
» » > Detail - 7.9.4  - RM Info: why isn't this in routing  header?
» » >
» » > Proposal -  Move to Routing Header
» » > Resolution -
» » > Response By - December 21
» »
» » I  have to disagree with this. The ReliableMessagingInfo
» » element  applies to the message, not to a particular hop
» » along the way. Note  that David has crafted a revised section
» » on RM in the draft we've  been collaborating on which we
» » hope to get to the list today  (although, we recognise that
» » it still needs work).
» »
» » >
» » > ####
» » > Issue 16
» » > Title - TPAInfo
» » >  Detail - Add new section containing all TPA(CPA) information
» » >
» » > Proposal - see above
» » > Resolution -
» » >  Response By -
» »
» » This one I'm not sure I understand. I thought  that we agreed
» » in Tokyo to flatten the TPAInfo section by moving all  of
» » the child elements to be direct decendants of Header.
» »
» »  What information was missing from TPAInfo anyway? I'm not
» » clear on  what the proposal really suggests.
» »
» » >
» » > ####
» »  > Issue 17
» » > Title - Sequence number
» » > Detail - 7.10  SequenceNumber as defined adds little or no value over
» the
» » >  MessageID element required in MessageData.  Recommend removing this
» » section
» » > and the corresponding references to  SequenceNumber in later 
» examples,
» » the
» » > DTD and the  schema.
» » > If this section remains, must define the exact content  of the
» » SequenceNumber
» » > element when the numeric value is  greater than 999.  Is the
» next value
» » > "1000" or  "1,000"?  Is the text for the maximum value  "999999999" or
» » > "999,999,999" or are both allowed (and equivalent)?  Side  note:
» Numeric
» » > formats vary by locale and a comma is not always  the thousands
» » > If this section remains, "long time" should be  defined.  At least,
» refer
» » to
» » > a TPA which makes this  concrete for a specific trading
» relationship or
» » > mention later  text on this subject (if any).
» » >
» » > Proposal -
» » >  Resolution -
» » > Response By -
» »
» » Since we're going to  spec the schema using XMLSchema, we can
» » be more precise in the  typing of elements and attributes.
» » I agree that the spec needs to be  tightened up for this
» » particular element.
» »
» » I'll have to  review David's revision of RM to see what that
» » has to offer.
» »
» » >
» » > ####
» » > Issue 18
» » > Title - URI  definitions in RM
» » > Detail - 7.10 - SenderURI, ReceiverURI and  ErrorURI are not
» » defined.  Are
» » > they identifiers or  service locations?  From later discussion in this
» » >  document, it appears that ErrorURI is a service location at which
» error
» » > responses may be received.  The other two aren't discussed  much.
» » However,
» » > I'd recommend they be defined similarly to  the PartyId
» elements in the
» » > Header (i.e. the parties  participating in the current leg of the
» » journey).
» » > That  requires adding a context attribute to SenderURI and
» » ReceiverURI and
» » > (potentially) renaming the elements.  Alternatively,  SenderURI and
» » > ReceiverURI may somehow identify the service  location used in this
» » > particular leg (this is probably  redundant information for
» ReceiverURI
» » with
» » > the transport  destination and SenderURI may not exist -- not all
» senders
» » are
» »  > reachable in return).
» » >
» » > Proposal -
» » >  Resolution -
» » > Response By -
» »
» » I assume that the  subject refers to URI elements in RoutingHeader
» » not RM. Agree that  these need to be more precisely defined.
» » As to defining them  similarly to the PartyId element...
» » I had actually proposed to David  in our discussions that
» » instead of defining different elements, that  we re-use
» » To and From but with precise wording that the PartyId
» » MUST be an URL form of URI (e.g. something addressable).
» »
» »  This also brings to mind a security issue (possibly) as
» » if an  intermediate signs a header (with the added RoutingHeader
» » element)  then it MAY be important to be able to identify
» » the intermediary  with the specific RoutingHeader. I hadn't
» » thought of this before,  but it MAY be important to consider.
» »
» » >
» » > ####
» » > Issue 19
» » > Title - Persistent storage
» » >  Detail - 7.11 - "Persistent storage" actually lasts how long?  Is the
» » > original message deleted by the Messaging Service immediately  after
» » > receiving an acknowledgement?  In the case of an  error, which
» » is reported
» » to
» » > the sending application  (party), does that report also result
» » in deletion
» » of
» »  > the original message from the persistent storage?
» » > What  information does the Receiver store persistently in this step?
» » >  Recommend storing the MessageID of the original message and
» the entire
» » > response document.  To check for "exactly the same as the  original
» » message"
» » > as described on line 828, may be  necessary to store entire original
» » message
» » > or its  checksum as well.
» » >
» » > Proposal - This is out of scope of  the TR&P if required it should be
» in
» » the
» » > CPP/CPA
» » > Resolution -
» » > Response By -
» »
» » David has  added a section on persistence in his RM draft
» » proposal. It doesn't  get into "how long" as this is correctly
» » identified as being  something that the parties MUST agree
» » upon and have reflected in the  CPA. A new element is being added
» » to the CPA for this purpose (e.g.  to capture the persistenceDuration
» » with which a message is to be  archived).
» »
» » >
» » > Ian Jones
» » > E-Commerce  Engineer
» » >
» » >
» »
»
»
»
»
»
»
»
»
»



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC