Comments on Elements / Parms in TRP MSS 0.98

[Cameron Young <cn_young@attcanada.ca>]

Comments are organized in decreasing priority.

1) Add "Transport Parameters" section to System Overview (Section 6)

With the addition of Via element its taking me a lot of mental work as a reader to try figure out the implied rules for handling parameters.  Here's my read of where information relating to the required behavior of a receiving MSH is located.  (use courier font)

                               +------------------------
                               | Embedded in Message
---------------------------+---+------------------------
Parameter                  |CPA|QOS|MsgData|TraceHdr|Via
---------------------------+---+---+-------+--------+---
deliverySemantics             y| y
deliveryReceiptRequested      ?| y
TimeToLive                    y|       y
syncReply                     y|                      y
reliableMessagingMethod       y|                y     y
ackRequested                  y|                y     y

I *think* this means that deliverySemantics and deliveryReceiptRequested (and TimeToLive)are characteristics supplied to the sending MSH by the application / CPA that has end-to-end scope.  Whereas, syncReply, reliableMessagingMethod, ackRequested could vary throughout multi-hop transit, and therefore have only transport-level scope (therefore in TraceHdr and Via).

If this is the case, it should be stated clearly somewhere.  I suggest adding a Transport Parameters section as Section 6.3.

2) Make TraceHeader a child of Via, rather than a separate element
It is amended on a per-hop basis, so localize it within the via element which has local hop significance.

3) Reorganize fields in SOAP Header / SOAP Body

This suggestion has taken a while to gel in my mind, due to the combination of the increased level of support for multi-hop operation (via element), and the new SOAP Header/Body separation.

In my mind at least there is a cleaner basis for separating Header / Body elements.

- Transport information supplied by the application / CPP that is delivered transparently between originating MSH and terminating MSH goes in the SOAP Body.

- Transport information generated or altered by the MSH or intermediate MSH's goes in the SOAP Header.

On single-hop links, the Header would be near empty, as all the information would be in the SOAP Body.

If that rule is applied, and by my logic, the split would become:

SOAP Header
    TraceHeader (or child of Via per 2 above)
    Via
        TraceHeader (per 2 above)
    ErrorList
    Signature
    Ack (type = Ack)

SOAP Body
    MessageHeader
        From
        To
        CPAId
        ConversationId
        Service
        Type
        Action
        MessageData
        QOSInfo
        SequenceNumber
        Description
    Manifest
    StatusData (not sure about this one)
    Ack (type = DeliveryReceipt)

Functionally, I don't think it really matters where the data is located, since both are visible to MSH's. (though maybe the signature would be cleaner with this approach.)

However, as a reader who is relatively new to this, it would make more sense to me if it was organized this way.

A minimally simple implementation (relying on external security such as SSL, and delivery Receipts) could generate messages using only the SOAP Body elements.

4) Service / Action:
Is there any reason not to make Action a child element of Service?  It looks conspicuous to me being a peer of Service.

5)  CPAId
The CPAId is defined as "a string that identifies the parameters that govern the exchange of messages between the parties ..." (line 426-427), and it "MAY reference an instance of a CPA as defined ...".

Could I not include in this field either an entire CPA, or a composite XML element explicitly defining the necessary parameters?

This should be explicitly allowed or prohibited.

Regards and all the best,
Cameron Young