Re: Comments on MS v0-21

[NEVE John <john.neve@swift.com>]

Thank you for the interesting document.
Hereafter my comments:

1. The examples in appendix B do not seem to implement the proposed structure: in particular for ebXML Header Document (Manifest &
Header).
2. The schema is a big help to clarify the text.  It brings the following questions:
2.1. To (line 634): Why not allowing multiple receivers?
2.2. ReliableMessagingInfo (line 703):
2.2.1. Are we sure there is a business justification in AtMostOnce value?
2.2.2. Shouldn't there be a value with meaning ‘at least 1, and if more, other occurrences must bear a Possible Duplicate Flag with
reference to previous attempts’?
2.3. MessageData (line 663): There should be more than 1 RefToMessageId allowed.
2.4. BusinessServiceInterface (line 715):
2.4.1. Multiple occurrences should be allowed.
2.4.2. Naming inconsistency with line 430 ‘ServiceInterface’.
2.5. Action (line 716): Multiple occurrences per ServiceInterface should be allowed.
3. A few suggestions for enriching the message structure within the ebXML scope (no intermediary type of exchange).  If some of
these receive interest from the community, I am ready to expand on them:
3.1. Within the Header Document:
3.1.1. A TestLiveMode flag with value Test or Live.  This would allow simulation, test or training before using a TPA service.  An
alternative is to define the test mode as part of the service, but having this flag has the advantage of emphasizing something
critical in many business operations, i.e. whether a message is a real business operation.
3.1.2. A set of elements under InstructionsForReceiver:
3.1.2.1. DeliveryAckRequested
3.1.2.2. PreProcessingInstruction
3.1.2.3. PreProcessingAckRequested
3.1.2.4. DeferredExecutionTimeRequested
3.1.2.5. BusinessProcessingPriority
3.1.2.6. ScenarioForDelayedProcessing
3.1.2.7. ProcessingInstruction
3.1.2.8. ApplicationAckRequested
3.1.2.9. ResponseRequested
3.1.2.10. RestrictionsOnResponse
3.1.3. An overall PayloadDescription set of elements including:
3.1.3.1. TransactionalContext
3.1.3.2. MessageContext including in particular the currently defined element MessageData
3.1.3.3. SenderValidationStatus
3.1.3.4. DecompressionIndications
3.1.3.5. DecryptionIndications
3.1.3.6. MessageContentsSyntax
3.1.3.7. The NumberOfParts and a PartDescriptor for each
3.1.4. More granularity in MessageType which could be renamed APDUType and contain values Message ACK Error and subtype e.g. Message
could contain Request or Response and ACK could contain DeliveryACK, PreprocessingAck, ApplicationAck.  Other APDUs could be
envisaged at least provisionally such as Cancel, OpenSession or OpenScenario or OpenConversation.
3.1.5. An optional expansion of Sender and Receiver(s) details allowing alternative addresses
3.1.6. E-Mail attributes for the Receiver(s): individual to/cc/bcc and global optional delivery notification & non delivery warning.

Thanks very much for your attention and your comments,

John N. Neve
Systems architect
Standards Department
SWIFT

Henry Lowe wrote:

> Note: This has not been sent to any other list as Klaus'
> message was not clear as to where comments should go.
>
> Henry
> ----------------------------------
> Comments on ebXML Messaging Service, V0-21, 13 Sept. 2000
> from Henry Lowe, 6 Oct. 2000
>
> Line 172: it is possible to carry more than one document in
>   the payload.  So, text should be modified to read:
>   "XML or other document(s) for the ebXML Payload."
>
> Lines 185 and 195:  There is no choice possible, so the text
>   "For example" should be replaced with "It must be".
>
> Lines 221 and 278:  There is a problem with the text not
>   completely matching figure 2-1 which makes it a bit difficult
>   to understand what is meant.  In particular, the figure doesn't
>   have a label on the "Container".  In actual fact, the light
>   and dark gray shaded boxes are the Containers -- they should
>   be labeled in the figure.
>
> Lines 267-269: In the example, Context-Type does not have its
>   attributes version & charset specified.  The text of section
>   2.3.3 says they MUST be present (of course, the default could
>   be assumed, but 2.3.3 say nothing of a default).
>
> Lines 283-284: The Payload Container can carry more than one
>   document by having appropriate references in the Manifest.  It
>   would be useful if something to this effect were added to this
>   section, probably in this paragraph.  Suggested text: "The
>   Payload Container may contain more than one document and the
>   Message Manifest provides references which allow documents
>   to be distinguished."
>
> Line 297:  The text "This is the implementor's decision" implies
>   it is entirely up to the implementor as to whether (s)he wants
>   to carry multiple documents and how it is done.  This isn't quite
>   the case as the Document Reference, section 3.2.1, is the
>   standardized method for distinguishing multiple documents.  A
>   statement to this effect and reference to 3.2.1 should be added.
>   It might, also, be nice to add another example in 3.2.1 illustrating
>   the case for multiple documents in the same payload container.
>
> Line 326: It is not clear what this means.  Explanation should be
>   added.
>
> Lines 403-416 (section 3.3.1): I thought we had agreed that PartyID
>   would be a URI.  This section should be updated accordingly.

--
This e-mail and any attachments thereto may contain information that is confidential and/or proprietary and is intended for the sole
use of the recipient(s) named above.  It is not intended to create or affect any contractual arrangements between the parties.  If
you have received this e-mail by mistake, please notify the sender and delete it immediately. Thank you for your co-operation.

begin:vcard 
n:Neve;John N.
tel;fax:+32 2 655 30 05
tel;work:+32 2 655 30 87
x-mozilla-html:TRUE
url:www.swift.com
org:S.W.I.F.T. s.c.;Marketing- Standards
adr:;;avenue Adele 1;La Hulpe;;B1310;Belgium
version:2.1
email;internet:john.neve@swift.com
title:Systems architect
fn:John N. Neve
end:vcard