RE: TPA Info Rework

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

Marty

Comments inline.

David

-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Friday, October 27, 2000 12:39 PM
To: Burdett, David
Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
Subject: Re: TPA Info Rework


(Again, I hit the send button in error.  Hmmm....)

David,

I like this proposal.  I am not speechless, however :-)

7.9.1 From and To

   Line 48:  CpaReferences:  Presumably should be CpaReference
##Correct##

7.9.1.2 ConversationId

   Line 65:  Can we delete "or more"?  There are some fairly serious
   run-time issues with more than 2 parties.  I would prefer to leave that
   for the future in both TP and TRP.
##Sounds like a good idea. I'm not sure how it would work in a mult-party
environment. Agreed##

7.9.1.3  CPA Reference

   Line 81 and 82:  The term we are using in TP Requirements is
   "Collaboration Protocol Agreement".
##Done##

7.9.1.4  Party Profile Reference

   Line 106 and elsewhere:  Currently, the TP team is using the term
   "Collaboration Protocol Profile".  Could we state that here instead of
   Party Profile.  Alternatively (and more controversially), the term
   Trading Partner Profile is reserved for a profile that contains a CPP
   and higher level definitions.
##For consistency I'll use CPP and CppReference##

   Editor's note, lines 125-131:  In my opinion, if a Party Profile has to
   contain more than one way of exchanging messages, that Party expects to
   work with the other party to select one way.  In other words, that's a
   situation which cries out for a CPA.  The CPA is the additional
   mechanism that the note refers to.  I suggest stating a RECOMMENDation
   that if a Party expects a CPP to be used in lieu of a CPA, it should
   limit the CPP to one way of exchanging messages and if the CPP has to
   state more than one way, a CPA should be used to define the choice for
   one pair of parties.
##Limiting it to one-way is a good idea, however what would you do if you
send a message to the same service using either RosettaNet or EDI?. If we
follow your route then we would have to have to CPPs. I think we need to
think this through some more as it ties in closely to the structure of the
CPP and how you can identifiy it. For example you could have something along
the lines of ...

<Cpp>
<Service Id='123' type='POAccept' >
<Protocol Id='456' type='EDI' />
<Protocol Id='789' type='RosettaNet' />
</Service>
</Cpp

... then the CppReference could contain ...

<CppReference>cppid:123:protocolid=789</CppReference>

... which I don't like since the content has structure that is not XML, or
...

<CppReference>
<cppid>123</cppid>
<protocolid>789</protocolId>
</CppReference>

... which is better but would require us to definie the structure ...
##

7.9.2 Service

   Line 193 and elsewhere:  I agree that ServiceInterface is not
   appropriate since that term usually refers to inter-layer interface in a
   protocol stack, and TRP seems to be going in that direction for its
   upper interface.  Other possible terms, some of which have been
   mentioned by members of the TP team are Collaboration Interface,
   Business Service Interface (assuming Stefano is willing to find another
   term for his Business Service Interface), and Logical Port.  Let's try
   to resolve this one on Monday of the Tokyo meeting.
##RosettaNet uses the term "Service", BizTalk uses the term "endpoints", I
am strongly in favor of the term "Service" ... we really need an agreed
glossary of terms.##


7.10 DTDs

   I prefer the first version (lines 221-242).
##So do I ;) ##
Regards,
Marty







****************************************************************************
*********

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************
*********



"Burdett, David" <david.burdett@commerceone.com> on 10/23/2000 08:30:05 PM

To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
cc:
Subject:  TPA Info Rework



Folks

The attached PDF and MS Word files contain a re-work for version 7.9 (XML
Header) of version 0.21d of the TRP Message Service Spec. The main reason
for doing this is to support the sending of messages without prior
agreement
of a TPA (CPA?). The introduction to the document provides a full
explanation of the changes made and the reasons why.

Comments are welcome. I also think we should discuss this in Tokyo.

David
 <<TPA Info Alternative 2.doc>>  <<TPA Info Alternative 2.pdf>>

Product Management, CommerceOne
4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com