Re: Reliable Messaging Spec v0-078

[Christopher Ferris <chris.ferris@east.sun.com>]

I basically feel that one is better than three. I seriously
doubt that we can separate the three at any practical level
for any implementation. Granted, from a usage perspective,
RM and Security might be *optional*, but I wouldn't want one
even if I were the smallest of SMEs. I would still want
both reliability and security;-)

Chris

Martin W Sachs/Watson/IBM wrote:
> 
> Rik,
> 
> At this point, I believe that one spec is much easier to read than three
> since all three (MS, RM, and security) cover the same architectural layer
> and contribute to the combined package or message header.  One spec,
> composed with care as to what is in separate sections, and with due
> attention to what tags should have cardinality 0 or 1 (I am trying hard not
> to use the word "optional" here since that will be interpreted in the
> RFC2119 sense), will be much easier to comprehend than 3 separate specs.
> 
> We could keep them separate initially, to get some parallelism in the work,
> as we are doing with RM, but they should come together before final
> approval.
> 
> 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
> *************************************************************************************
> 
> "Rik Drummond" <rvd2@worldnet.att.net> on 09/24/2000 08:00:01 PM
> 
> To:   "Jim Hughes" <jfh@fs.fujitsu.com>, Martin W Sachs/Watson/IBM@IBMUS
> cc:   <ebxml-transport@lists.ebxml.org>
> Subject:  RE: Reliable Messaging Spec v0-078
> 
> i don't think we have decided yet if we will have three distinct specs...
> ms, rm and security or whether we will roll them together... i prefer the
> former....  but that is up for the trp group to decide or maybe stc.... i
> think three shorter easier to read specs are better than one longer one....
> best regards, rik
> 
> -----Original Message-----
> From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> Sent: Sunday, September 24, 2000 3:02 PM
> To: Martin W Sachs/Watson/IBM
> Cc: ebxml-transport@lists.ebxml.org
> Subject: Re: Reliable Messaging Spec v0-078
> 
> Marty,
> 
> Thanks for the quick review and comments. There won't be any update before
> the discussion on Wednesday, so we'll introduce your comments if you won't
> be coming...
> 
> By the way, it is my understanding that all this RM material will have to
> be worked into the basic MS document, so relative to your comments on
> structure/terms/etc. there will be more work in this area. I'm more
> concerned at this point to get agreement on the basic principles so that we
> can finish a document for POC use.
> 
> Jim
> 
> At 12:01 PM 9/24/2000 -0400, Martin W Sachs/Watson/IBM wrote:
> 
> >Here are my comments on RM v0-078.
> >
> >2.2.2  Message Header - RM Info
> >
> >154:  Please change "temporarily persistent" to "persistent" everywhere.
> >"Temporarily persistent" is a contradiction in terms. Somewhere in the
> spec
> >there can be a non-normative discussion of when a message can be discarded
> >from persistent storage.  In fact, unless the message is retained in
> >persistent storage by at least one of the parties until it has been
> >completely processed by the higher level, it can be irretrievably lost
> >under failures such as software or node failure.
> >
> >155: Please replace "requests unreliable messaging semantics" by something
> >like "indicates that the RM service is not to be used".  The parties may
> >have an alternative way of obtaining reliability such as by using a
> >reliable transport protocol.
> >
> >162:  See my comments on section  7.
> >
> >167:  I agree that "unspecified" is unclear but so is "best effort" (see
> >comments to sect. 7).   We need a keyword which simply says that this RM
> >service is not to be used.
> >
> >2.2.3  Routing Header
> >
> >173-176:  What new function does MessageServiceId provide that isn/t
> >provided by SenderId and ReceiverId?  These implicitly define a specific
> >instance of the MessagingService.
> >
> >184: (Table 2.2):
> >
> >    3rd line and first bullet:  Please replace "transport" by "messaging
> >    service instance".
> >
> >    3rd bullet:  "a long time" is ill defined. One partner may choose a
> >    different time to reset the sequence number than the other, thus
> leading
> >    to spurious error indications.  We should either define an event which
> >    is visible to both parties that causes reset of the sequence number or
> >    require that the sequence number be preserved "forever".  Even "for
> the
> >    life of the messaging service instance" is ill-defined.
> >
> >2.3  Message Transfer Sequence
> >
> >187:  Please state that the message shall be stored in persistent storage
> >before sending the acknowledgment message.  Even though this is described
> >later, this is a key point that should be mentioned up front to avoid
> >confusion.
> >
> >190:  State that the next message cannot be sent until the acknowledgment
> >to the previous message is received.
> >
> >193:  Fig. 2.2 does not (and should) make it clear that the receiver must
> >put the message in persistent storage before sending the acknowledgment.
> >
> >205-206:  This could be interpreted to read that the message is "processed
> >appropriately" before step 4 takes place. Please delete "and processes the
> >message appropriately".  An informative note could be added that it is
> >permitted to pass the message to the application  for processing
> >concurrently with steps 4 and 5.
> >
> >214:  Please add "or later failure recovery".
> >
> >2.5  Detection of Repeated Messages
> >
> >225-226:  It may be worth repeating here that the sequence number is
> >actually qualified by the senderId.
> >
> >234:  Yes, a duplicate ACK shall be sent.  The sender may be (probably is)
> >sending a duplicate because it didn't receive the first ACK.  Do we need
> to
> >require that a timer be set on the ACK?
> >
> >235:  (note following this line)
> >
> >    (a)  See my comment above regarding "for a long time".
> >
> >    (b) This is precisely why "for a long time" is not a proper
> >    specification (see comment above).
> >
> >273:  (3) Since this algorithm specifically uses the sequence number, case
> >3 is by definition identical to case 2. Only the sender can know that the
> >second message is not a duplicate even though it has the same sequence
> >number. This cannot happen if we agree to my foregoing comments about "for
> >a long time".
> >
> >2.6  Reliable Messaging Acknowledgment
> >2.6.1 General
> >
> >246:  At this time, the messaging service cannot handle communications
> >protocol function since it is, by definition, blind to what is going on at
> >the transport level.  See my comments to section 2.6.3.
> >
> >248:  (3) Please change "timeout" to "messaging service timeout".
> >
> >248: (4) We have not provided a separate definition of transient errors.
> >An error cannot be declared transient until it has been recovered.  A
> >transient error manifests itself as a timeout for which the retry
> succeeds.
> >A repeated-sequence-number error is a messaging error, not a transient
> >error.
> >
> >2.6.2  Reliable messaging formats
> >
> >270:  Please delete this line.  ServiceInterface and Action are present in
> >all messages, whether reliable or not.
> >
> >2.6.3  Communication Protocol Errors
> >
> >274-292:  In the absence of a set of definitions which specify the
> >information flow between the MS and the transport level, the MS is blind
> to
> >what goes on in the transport level.  Architecturally, the functions
> >defined here are part of the transport level. In practice, an
> >implementation may or may not have a boundary between the messaging
> service
> >and transport level but that is an implementer's choice.  Please remove
> >this section.  See my comments to section 3 below.
> >
> >2.6.5  Timeout
> >
> >302:  Please replace "final" by "previous".
> >
> >306-307:  This is going on in the sender.  The sender does not return an
> >ACK or error message.
> >
> >2.6.6  Transient Errors
> >
> >314ff:  See my comment on transient errors above.
> >
> >2.6.8  Maximum Number of Retries...
> >
> >343:  Please supply a definition of "retry interval".  It is the minumum
> >required time between successive retries.  Please remove the keywords
> >RetryInterval and Retries.  The TP team has not yet started defining tag
> >names.  There are two other such pairs also to be named (transport and
> >business level).  Please state that the retry interval and number of
> >retries discussed here are specifically for the reliable messaging
> service.
> >
> >348-350:  Please delete this statement or make it non-normative.  The
> >recovery action following such an error could be quite different, even
> >perhaps involving a reboot.
> >
> >3. Relationship with Transport Level
> >
> >353ff:  This section appears to be about the MS in general, not about RM.
> >As such, it does not belong in this document.  This can be considered the
> >beginning of the work we need to do on tying the MS and the transport
> level
> >together.  I suggest putting this section and section 2.6.3 into a
> separate
> >draft proposal and continuing to flesh it out on a time scale appropriate
> >to the deliverables schedule.
> >
> >5. TPA Considerations
> >
> >392ff:  It should be made clear that the actual tag names are TBD by the
> TP
> >team.
> >
> >7. Definitions
> >
> >Per an editor's note earlier in the document, the semantics terms need
> >reconsideration.  Until this point, I understood "atMostOnce" to be what
> >the RM service provides. I think I agree that as currently defined the RM
> >service provides ExactlyOnce.  In this section, "atMostOnce" seems to mean
> >that the RM service provides duplicate detection but not retries.  That
> may
> >be so but this spec does not provide that option.  "BestEffort" is out of
> >scope for the MS because it specifies what the parties (i.e. application
> >level) do.  Please delete "BestEffort" and the last 2 bullets (party
> >definitions) of "AtMostOnce".  From the MS viewpoint, the two are the
> same.
> >In addition, we need a choice that specifies "RM service not used".  For
> >this option, there are neither duplicate detection nor retries.
> >
> >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
> >
> ***************************************************************************
> **********
> >
> >
> >
> >Jim Hughes <jfh@fs.fujitsu.com> on 09/23/2000 06:59:43 PM
> >
> >To:   ebxml-transport@lists.ebxml.org
> >cc:
> >Subject:  Reliable Messaging Spec v0-078
> >
> >
> >
> >Attached are Word and PDF copies of the latest version of the Reliable
> >Messaging Spec, for discussion on Wednesday in the F2F. Shimamura-san has
> >added much more detail on reliability issues, and of course the earlier
> use
> >of Message Groups is now deleted for simplicity. Since there were many
> >changes, I deliberately did not mark changes in this document, but you can
> >easily see them by using Word's compare utility against the previous
> >version.
> >
> >[Ralph, could you have some copies of the document available on Tuesday,
> >for those that might not have access to a printer before travelling to
> >Dallas?]
> >
> >Jim

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903