RE: TRP Work Plan - Version 17 Aug 00

[David Burdett <david.burdett@commerceone.com>]

See comments inline

David

-----Original Message-----
From: Henry Lowe [mailto:hlowe@omg.org]
Sent: Thursday, August 24, 2000 6:19 AM
To: David Burdett
Cc: 'Henry Lowe'; 'gvh@progress.com'; 'mwsachs@us.ibm.com'; 'Jim
Hughes'; ebxml transport
Subject: RE: TRP Work Plan - Version 17 Aug 00


David,

That's the problem with a 3 hours time difference -- I'd gone home 
before your reply arrived.

No, that was not the interface I was thinking of, however, this 
one will do nicely for looking at parameters.  Would the I/F you're 
referring to have several difference invocations, one for each of 
the several functions you mention below, or would there be one 
invocation and you'd differentiate the functions with parameters 
on the invoke? 
>>This is purely an implementation decision. I would though, expect that
groups/standards organizations for particular language bindings would
provide normative representations in that language.<<<

 Would any of these parameters affect (change) Headers?
>>>In the examples I gave, probably not, but in principle they could.<<<

The I/F I was thinking of (I was flying by memory) was actually 
the one on the left fromthe Repository.  Just looking at the diagram, 
I would guess that information from the Repository passed via that 
I/F would be used to put values into the Headers of a message to be 
sent, e.g., assuming the TPA is in the Repository the TO info may 
be passed via that I/F.  Is this the case?  Without words to go with 
the diagram, it's hard to know what all the arrows imply.
>>>The data from the Registry would definitely affect what went in the
headers. I also agree that the diagram needs an explanation - I just don't
have the time to do one right now - any volunteers?<<<

Henry
-------------------------
At 02:58 PM 08/23/2000 -0700, David Burdett wrote:
>Henry
>
>When you say " there was an arrow (API) from the TPA to the Messaging
>Service" do you mean from the Application to the Messaging Service? If you
>mean this arrow, then I mean that sometimes the application wants to know
>about the delivery of the document.
>
>A real world analogy might be making a telephone call to the mail room to
>check that the package you asked them to delivery got there.
>
>More precisely I expect this interface to include primarily inquiries such
>as on (not a complete list): whether a message has been sent, receipt of
>acknowledgement, authenticity of a digital signature. All these things can
>have a business relevance and therefore interfaces to them should be
>exposed.
>
>David
>
>-----Original Message-----
>From: Henry Lowe [mailto:hlowe@omg.org]
>Sent: Wednesday, August 23, 2000 2:44 PM
>To: David Burdett
>Cc: 'Henry Lowe'; 'gvh@progress.com'; 'mwsachs@us.ibm.com'; 'Jim
>Hughes'; ebxml transport
>Subject: RE: TRP Work Plan - Version 17 Aug 00
>
>
>David,
>
>I mean that some of the information necessary to send the message 
>to the recipient could be in the parameters -- I wasn't thinking 
>of puting it in the Message Headers.  
>
>However, this one phrase is sort of taken out of context.  I'm not 
>advocating doing things this way.  Just trying to point out the 
>alternative.  I, like you, would rather see all the information 
>contained in the Message Headers -- that's why I'm creating about 
>the lack of routing information in the Headers.
>
>On the other hand, think back to your diagram of yesterday, there 
>was an arrow (API) from the TPA to the Messaging Service.  What 
>info was conveyed and in what form?  
>
>Best regards,
>Henry
>------------------------------
>At 12:45 PM 08/23/2000 -0700, David Burdett wrote:
>>Henry
>>
>>You said below ...
>>
>>"everything must come from the message itself and excludes some of it
>coming
>>from parameters of the (conceptual or real -- take you choice) service
>>interface"
>>
>>What you mean by "coming from". Do you mean that the Service Interface
will
>>contain some parameters that will be included in the ebXML Document
Header?
>>
>>David
>>-----Original Message-----
>>From: Henry Lowe [mailto:hlowe@omg.org]
>>Sent: Wednesday, August 23, 2000 8:17 AM
>>To: David Burdett
>>Cc: 'Henry Lowe'; 'gvh@progress.com'; 'mwsachs@us.ibm.com'; 'Jim
>>Hughes'; ebxml transport
>>Subject: RE: TRP Work Plan - Version 17 Aug 00
>>
>>
>>David,
>>
>>Please see single comment embedded below for context.
>>
>>Henry
>> 
>>At 02:44 PM 08/22/2000 -0700, David Burdett wrote:
>>>Henry
>>>
>>>We have from the requirements and overview document ...
>>>>>>
>>>1) Servers/systems that support the exchange of documents shall be
treated
>>>as "black boxes"  
>>>2) The method used to transport documents shall be completely independent
>>>of:
>>>  a) the hardware used by the server/services at each end 
>>>  b) the software or systems architecture of the server/services at each
>>the
>>>language used for implementation of systems and applications.
>>><<<
>>>
>>>I think these requirements imply that one party need have no knowledge of
>>>the technology used by the other party. In turn this means that:
>>>1. A party must be able to discover *everything* they *need* to know just
>>>from the message, and therefore
>><hal>
>>I'm not sure the quote above says that everything must come from the 
>>message itself and excludes some of it coming from parameters of the 
>>(conceptual or real -- take you choice) service interface.  While I 
>>can't speak for Gordon, I read between the lines (always dangerous) 
>>that he saw some of this info coming from these parameters.
>></hal>
>>
>>>2. We must write the ebXML Messaging Services spec so that they can
ignore
>>>the service interface spec **if** they want to.
>>>
>>>Please understand, that I think a service interface spec will be a very
>>>useful thing to have (in fact we wrote one for IOTP). I'm just arguing
>>that:
>>>1. The ebXML Messaging Services Spec should not have to rely on it
>>>2. Implementers don't have to built to it if they don't want to.
>>>
>>>David
>>>
>>>
>>>-----Original Message-----
>>>From: Henry Lowe [mailto:hlowe@omg.org]
>>>Sent: Tuesday, August 22, 2000 1:40 PM
>>>To: David Burdett
>>>Cc: 'gvh@progress.com'; 'mwsachs@us.ibm.com'; 'Jim Hughes'; ebxml
>>>transport
>>>Subject: RE: TRP Work Plan - Version 17 Aug 00
>>>
>>>
>>>David,
>>>
>>>You are stating a goal for our Headers here.  Did we ever agree 
>>>to this goal, i.e., all info necessary for message exchange be 
>>>contained in the Header?  I'm not saying this is a bad goal, but 
>>>if we are not all singing from the same book, we may not agree. 
>>>
>>>
>>>I believe Gordon pictures some additional info being conveyed 
>>>in the parameters of the API, be it real of conceptual.  Personally, 
>>>I rather like this goal as it severly constrains the API parameters 
>>>to be trivial.
>>>
>>>Henry
>>>-------------------------------------------
>>>At 12:50 PM 08/22/2000 -0700, David Burdett wrote:
>>>>Gordon
>>>>
>>>>I agree that awareness of the Interface is a benefit. I disagree that
>>>>"implementations of the wire protocol will require semantic knowledge
>that
>>>>is not imparted stricly from the fields in the header".
>>>>
>>>>If we can't fully define, in our spec, the meaning or semantics behind
>...
>>>>1. each field in the header
>>>>2. the meanings implied when these fields occur in combination within a
>>>>header
>>>>3. the meanings implied when messages (e.g. a normal message and it's
>ack)
>>>>are received in a specific sequence
>>>>
>>>>... then, IMO, we are not doing our job properly.
>>>>
>>>>If we REQUIRE that particular type of interface is used to make an ebXML
>>>>Messaging Service Spec work, then we are creating an additional barrier
>to
>>>>its use.
>>>>
>>>>David
>>>>
>>>>-----Original Message-----
>>>>From: Gordon van Huizen [mailto:gvanhuiz@progress.com]
>>>>Sent: Tuesday, August 22, 2000 4:07 AM
>>>>To: David Burdett
>>>>Cc: 'mwsachs@us.ibm.com'; 'Jim Hughes'; ebxml transport
>>>>Subject: Re: TRP Work Plan - Version 17 Aug 00
>>>>
>>>>
>>>>
>>>>
>>>>David Burdett wrote:
>>>>> I think it should be possible for two parties communicating using the
>>TRP
>>>>> spec to achieve COMPLETE interoperability without implementing ANY of
>>the
>>>>> Interface spec - i.e. conformance to the wire protocol alone should
>>>>suffice.
>>>>> Do you agree?
>>>>
>>>>My assertion would be that successfully achieving interoperable
>>>>implementations of the wire protocol will require semantic knowledge
>>>>that is not imparted stricly from the fields in the header themselves
>>>>and can benefit from awareness of the Interface. But that's just a
>>>>hunch, since we aren't "there" yet. Regardless, the two levels must be
>>>>kept in synch for a developer to stand a chance of implementation, as
>>>>well as for us to actually get the spec work done. Witness the deltas
>>>>that are appearing elsewhere.
>>>>
>>>>-gvh-