RE: ebXML Proof of Concept Proposal v0.5

[Marc Breissinger <marcb@webmethods.com>]

Thanks Prasad.  See my answers/comments below in blue.

 

marc

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Thursday, July 27, 2000 11:11 PM
To: marcb@webmethods.com
Cc: ebXML POC Mailing List
Subject: Re: ebXML Proof of Concept Proposal v0.5

Marc,

Looks great! What a transformation! I must commend you on producing such a professional document in such a short period

Few comments and questions. I italicized and quoted the text that is taken directly from the proposal document.

1. When we say "trading partners can by dynamically added to the network and participate in processes by declaring which roles they will fulfill", how dynamic are we mean? and what is involved in "declaring"? I mean are we using these in "electronic" sense or more like with a 'short notice to the people coordinating the demo', so that some sort of set-up, configurations can take place? I take it, it is the latter.  

You are correct.  It is the latter, but it should be minimal (i.e., tpa exchange and set up).

2. Is there any significance to / order implied by, the outer circle in the proposed trading network diagram.  

 Nope.

3. In the description under "Payloads", I don't quite understand what is meant by the second sentence in the text that I reproduced below. Can you please clarify / elaborate?
    "Payloads generated for the messages should adhere to the appropriate RosettaNet PIP 3A4 DTD specifications.  Additionally, those participants assuming the role of “Requester” in the environment must publish any field mappings from their request message that are required for the “Responder” to generate a valid response/acknowledgement message"  

The idea was that if a requester was actually generating PO data from some back end system, and needed certain information to be present in the response/ack payload in order to process the response/ack correctly, the requester must state what they need so responders could respond appropriately. 

4. Hub Routing:  It says, "This proof-of-concept will utilize a hub-spoke model.".
    a. Are we saying for August, we will NOT use point-to-point?
    b.  Did we decide we would use HTTP only for Hub, or is the intention to use the Hub model with SMTP also. If latter, I take it Philippe is o.k. with that.  

Not necessarily, but the environment will be configured with a hub-spoke model in mind and we will definitely plan on demonstrating a hub-spoke scenario.  Participants can use any protocol for communication with the hub that is supported by the hub.  I believe at this point that Viquity only does HTTP, so... 

5. If SMTP is part of the Hub model, I am not sure if we can guarantee "hub should not cause any alteration of the envelope, header or payload of the messages". I mean SMTP (mail) servers are likely to add additional headers to the (transport) envelope, which gets into the message envelope also (per ebXML scheme)!  

The point was that the hub should not alter the ebXML message envelope, header or payload.  The transport envelope can be modified at will.  In fact, part of the value add of the hub could be to connect partners that support different protocols that otherwise would not be able to talk to each other.  This does bring up a larger issue on maintaining the separation of the ebXML Message Envelope from the transport envelope.  For example, if we truly maintained the spearation of the ebXML MIME message envelope from the transport envelope, an HTTP transport ebXML message would look like the following:

 

POST destination-server- ebxmlhandlder-URI HTTP/1.1

Host: destination-server-domain:destination-server-port

Content-Type: multipart/related;

              charset="iso-8859-1";

              boundary= transport-envelope-boundary

Content-Length: int-length [units based on content-transfer-encoding]

 

-- transport-envelope-boundary

Content-Type: multipart/related;  

               type=”application/vnd.eb+xml”;

               charset="iso-8859-1";

               version=0.1 ;

                            MIME-Version=1.0 ;

               boundary=ebxml-envelope-boundary

Content-Length: int-length [units based on content-transfer-encoding]

 

-- ebxml-envelope-boundary

Content-ID: uid@originator-domain 

Content-Length: int-length [units based on content-transfer-encoding] 

Content-Type: application/vnd.eb+xml  

<?xml version="1.0" encoding="UTF-8"?>

<ebXMLHeader>

 ....

</ebXMLHeader>  

--ebxml-envelope-boundary

Content-ID: uid@originator-domain

Content-Length: int-length [units based on content-transfer-encoding]

Content-Type: ???/???

  

< Payload >

         --ebxml-envelope-boundary--

--transport-envelope-boundary--  

 

This scheme would allow for a hub to route a message without affecting the ebXML message envelope.  The hub could switch protocols from HTTP to SMTP to FTP to whatever without affecting the ebXML envelope.  However, the current packaging specification mixes the definitions of the ebXML message envelope with the transport envelope and we should follow the specification.  Thus, I suppose we have to allow the hub to alter the ebXML envelope (much to my dismay).

6. In "Packaging" section, it says:

"It should be noted that there is a significant problem with the current draft of the packaging standard that effectively prevents the receiving application from recognizing the header part.  The RFC for generating MIME Content-ID mandates only that they be unique strings.  Therefore, the receiving application cannot depend on the presence of the “ebxmlheader” and “ebxmlpayload” tokens preceding the unique id to identify the header vs. payload parts.  In order to resolve this issue in the demonstration environment, participants must include the “Start:” directive shown in the example above."

 I am sorry, that is not the case anymore. The spec is very clear on the Content-IDs being unique. I believe this was a problem in one of the earlier versions. The current spec reads:

"The value for Content-ID should be a unique identifier, in accordance with RFC 2045. An example usage follows:
Content-ID: ebxmlheader-com-8760-2000-0722-161201-123456789"

Also, the "Start: uid@originator-domain [from header Content-ID]" should be a parameter to the multipart/related content-type, not a separate header element (if used). Since ebXML packaging spec does not require it. may be we could drop it.  

I have altered the document to reflect the use of "Content-Type" for identifying the header part.  It should be noted, however, that this scheme precludes the possiblity of including a fully formed ebXML message as a payload part.  Chris has related to me that this decision was made and accepted during the face-to-face in Boston, so I will follow that decision.

7. Again in packaging (para following the above) says:   "It should also be noted that the payload Content-Type must be application/x-rosettanet as outlined in the RNIF 1.1 specification."

I am sorry, that is not true. It should simply be "application/xml". The example ebXML message "payload" content-type also must be changed to application/xml from "application/x-rosettanet".  

You are, of course, correct.  My bad.  I will change in the doc.  However, it does bring up an interesting question for the broader group.  Namely, if ebXML TR&P is allowed to carry many different kinds of payloads from many different standards, should we enforce a requirement that vertical industry payload standards conforming to ebXML standards define a unique sub-type?  That would allow an ebXML service provider to route a RosettaNet payload to a generic RosettaNet handler, an OAG payload to an OAG handler, an OTA payload to an OTA handler, etc.  Just a thought.

  

8. From the description in the "Transport" section, it is not clear to me if are planing to show use of SMTP (and other transports) for August or not (or) are we shooting for HTTP and Hub scenario only. The text seems to imply that. Can you please clarify.That is all I have.  

We can decide that in San Jose if enough people support SMTP to make it part of a demonstrable scenario. 

Thanks, Prasad
 

Marc Breissinger wrote:

All,

Attached is latest rev of the POC proposal.  Please read through and respond
with comments.  I will complete the TPA section tomorrow.

Sorry for the delay,
marc