RE: POC more nuts and bolts clarity

[Marc Breissinger <marcb@webmethods.com>]

Thanks for the comments Prasad.  See responses inline below.

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Monday, July 31, 2000 7:43 PM
To: ebXML POC Mailing List
Subject: POC more nuts and bolts clarity

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).  

Oops.  It has been removed. 

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.  

Oops again.  Cut and paste - what can you do?  I have removed it from the multipart/related parts. 

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.   
     
     Added. 
     
  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?  

 

Not really.  But I'd like to maintain consistency of vocabulary (i.e., we don't use the term initiator anywhere).    I don't believe there is a need to require processing beyond that required to generate the responses and acks.  I will add this clarifying description into the Vendor Roles section and move the Vendor Roles section up to immediately follow the Business Process section.

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".  

Done. 

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?  

I believe the header defs already specify this (i.e., they are all of the same format "/requester-DUNS/responder-DUNS/PIP3A4/1.1" where the entities playing the role of requester & responder remain fixed throughout the entire process.  So I guess I agree.

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.  

I don't see a need for that requirement.  The point was to make clear that the id value must be a unique id (uid) within the context of the sender/receiver (@domain), depending upon the specific id.  The actual format of the id does not matter.  If you are persisting this id, you should assume unstructured, free-form text (possibly including punctuation like ':' or '@').

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.  

I believe the header defs already reflect this  (in the '[from request message]' text).

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.  

I believe the header defs already reflect this although I did change the text explanation for the message four's RefToMessageId to say '[from acceptance message]' to match the terminology change suggested above.

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 " ".  

Agreed, but, since I managed to go and get myself engaged on Friday night, I did not get a chance to generate said example.  It might be best if we enlisted Marty or John (from IBM) to rip one out quickly based on the POC doc?  That way, we could ensure that the elements of the tpa are being utilized as intended in the draft spec.  Think they'd be up for it? 

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?  

I'll leave that one up to Chris.  I don't know if it was decided that we would officially add this to the header spec or leave it be an element/attribute in the tpa.  I have no strong opinion one way or the other (hard to believe, huh?). 

Thanks, Prasad