Registry Services, TPA formation, and TPA-Registry Responsibiliti es.

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

I have now read the "Objectives and Scope" for the TP team,
the Registry Services drafts from Farrukh, the Registry
"Business Domain" draft, and wish to raise a question:

Let TPP= trading-partner/party-profile.
Let TPA= trading-partner/party-agreement.
Let TPF= Bilateral TPA formation process from TPPs.

Should there be a TPF that is _independent_ of the Registry?

In the "Objectives and Scope" document, point 16 says that the spec
"Harmonizes with other ebXML specifications while being able to
be used independently of them."

If this is still an objective, I think we need to consider
more use cases and also reconsider what is needed for
the service layer(s) in TPF.

I previously supplied some use cases, at least one of which does
not require registry services, except maybe to register/retrieve
TPPs.

Closely related to this issue is whether we have
both negotiation and discovery based TPFs.

Business rules applied when negotiating TPAs may not be
information that users wish to export to a registry.
I get the impression that the TPF process
is to be carried out by processes within the registry. 
This would be ok if there are no "choices" involved (that is
the TPA is some purely mechanical merge of TPPs-- a macro
subsititution of roles to TP ids, for example). 

But when there are, for example, multiple delivery channels, business
policies may apply to the choice among channels and may
be based on outside information about the proposed TP. For example,
a company may do a look up on DUNS number of its proposed Trading
Party to find the company's credit worthiness and then select
what channel is to be used. (Small volume, SMTP; large volume,
set up an account, password and directory for FTP, and so on.)