RE: revised requirements

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

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Saturday, September 09, 2000 12:43 PM
> one general issue that I raise that I would like to repeat here ...
> 
> <snip>
> Do we want to restrict the TP groups work to just business 
> relationships.
> Electronic documents can be sent between two parties when there is no
> "business" relationship. Particularly, the functions in the 
> ebXML Messaging
> Services spec, e.g. reliable messaging, equally apply to business and
> non-business situations. If we wish to restrict our usage to 
> ONLY business
> relationships then using the term Trading Partner is fine. If 
> we don't then
> we should replace the tern "Trading Partner" as used in 
> Trading Partner
> Agreement and elseweher by something more neutral such as "Party" (see
> definitions below).

David,

Is the issue here that some exchangers of documents may not actually
be trading partners? (That is , they may be marketplaces, hubs, vans
or whatever?) 

Or do you want to open up the scope of this so that mailing lists,
anonymous ftp sites, my PPM access to CPAM perl modules, and all
other web based document transfers become part of 
the tasks for ebXML TPA WG? If we open
up the scope much beyond ebXML message services, 
I think this is going
to become a general web service discovery initiative, 
like UDDI and other service directory efforts.
Why repeat those?

I do not want to discourage precise usage of language and reasonable
diction, but "trading party" is far from neutral in its connotations;
to me it still suggests economic transactions of some sort (but maybe
more or a Tupperware variety :-).

Aside from the word choice problem, can you respond by
explaining the shift in the scope of effort 
that you are proposing -- this would help me understand 
this issue better. Sorry to be obtuse on this but 
I want to understand what I would be buying into here.


Dale Moberg


> 
> We haven't properly discussed this as an issue but, IMO, we 
> should. If we
> can't quickly come to a consensus, I think a vote is a good 
> idea as then the
> issue will be resolved once and for all.
> </snip>
> 
> David
> 
>