POC more nuts and bolts clarity

[Prasad Yendluri <pyendluri@vitria.com>]

Folks,

In preparation for freezing POC proposal tomorrow (as Nick suggested), I am listing below the items that we could use as a reference list for discussion tomorrow. If anyone sees anything else, please add to the list.

1. The Start header is removed from "Packaging" section but, still present in the "Transport" section. This needs to be removed from there (HTTP headers) also (page 10 of the latest draft).

2. In both "Packaging"  and "Transport" sections, the (top-level) multipart/related parts are shown with,
    Content-Length: int-length [units based on content-transfer-encoding]
The "units based on...." part in brackets above is not applicable since, multipart/related type does not have content-transfer-encoding (Multipart content-types cannot have encodings). I suggest we remove it for clarity.

3. What exactly the companies playing different roles need to be able to send and receive may not be clearly defined (as Jacques pointed). Here is my interpretation:

• Requester – an initiator of the demonstration business process

The requester as the initiator of the business process (PIP3A4) needs to be able to:
1. Send (3A4) Purchase Order Request Action and Receipt Acknowledgment for (3A4 PO Acceptance). (See arrows 1&4 in figure 2 in POC proposal). Marc: Can we number the figures? Thanks.
2. Receive (and process?) Receipt Acknowledgement  for (3A4) Purchase Order Request Action  and the 3A4 (3A4) Purchase Order Acceptance Action. (See arrows 2&3 in figure 2 in POC proposal).
• Responder – the target of the message sent from the initiator

The responder should be able to:
1. Send (and process?) Receipt Acknowledgement  for (3A4) Purchase Order Request Action  and the 3A4 (3A4) Purchase Order Acceptance Action. (See arrows 2&3 in figure 2 in POC proposal).
2. Receive (3A4) Purchase Order Request Action and Receipt Acknowledgement for (3A4 PO Acceptance). (See arrows 1&4 in figure 2 in POC proposal).
• Requester/Responder – a trading partner that is able to both initiate a demonstration business process and receive the message from another initiator.

The "Requester/Responder",  when playing the role of "Requester" must be able to send and receive the messages shown for "Requester" above and when playing the role of "Responder" must be able to send and receive the messages shown for "Responder" above.

Any Issues with above interpretation?

4. TPAInfo.Action I suggest we use the RosettaNet *specified* names consistently for all. I think we need to change only the one for "3A4 PO Response". It should be "Purchase Order Acceptance Action". This impacts the 3A4 PO Response xml instance (pp6,7) but,  in order to avoid any confusion I suggest we use the term "Purchase Order Acceptance" where ever we used "PO Response".

5. The TPAInfo.TPAId URI, is set by the "initiator" of the PIP (i.e. sender of the "PO Request" message) and stays at the "same value" for all messages (the PO Acceptance and the two Acks) in the PIP instance. That is, "/initiator-DUNS/responder-DUNS/PIP3A4/1.1" (e.g. /111111111/222222222/PIP3A4/1.1) stays fixed for the entire PIP instance (all four messages). Agreed?

6. Content-Id values: Are we *requiring* them to be in the form <uid@domain> form?, where uid is some number unique within the "domain" and domain is, message sender / receiver domain as the case may be (e.g. vitria.com). An example instance 1111@vitria.com, 1112@vitria.com so forth.

7. The "TPAInfo.ConversationId" (UUID in the form uid@domain) must also stay at a fixed value for all four messages in the PIP. This value again is set by the "initiator" of the PIP, just like the TPAInfo.TPAId.

8. This is probably obvious but, the MessageId.RefToMessageId *must* have the value for the message that this is in response to. That is, in figure 2, messages 2 & 3 must have the value for 1 and 4 must have the value for 3. 1 of course has the value "Not Applicable" as shown.

9. In the new TPA section, some of the element's purpose is sort of straightforward but, others are not so obvious. Since we are requiring people to supply this, we need some details on the purpose of and semantics of the many of the elements. For example,  the "DeliveryChannels" and the ids used in there etc., what is the purpose of these and do they have any relevance outside the TPA itself? That is, do they go in any field in ebXMLHeader for example (I guess not but).. This seems too complex to use at such a short notice. Can we simplify this? A completely filled out example that we could use is needed. I mean, a number of fields are left blank in there. For example <Participants>.<Member>.MemberId is supposed to give the DUNS number but, in the example instance it is " ".

10. The ebXMLHeader specification does not have a "version" attribute for TPAInfo.Action element.  The example ebXMLHeaders all have it. Actually we need it (I think Chris was also planing to add), but it is not there in the spec yet. So, should we go ahead and modify the DTD to add the version attribute?

Thanks, Prasad