Re: tpaml spec

[srh@us.ibm.com]

We (IBM) are helping with upcoming work in Core Components to have
discussions closer with CPExchange which is doing
work directly with Contact Information with specialization structures for
PostalAddress, email, telephone, website, etc.
Further, OTA has Contact Information also, and the members are active in CC
as well. This sort of information best
left up to the CC workgroups.

I suggest we only have extension stubs in place for Contact Information of
the Members in the TPA.

Scott Hinkelman
Senior Software Engineer, SWG IBM Austin
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Martin W Sachs/Watson/IBM@IBMUS on 07/18/2000 12:36:42 PM

To:   David Boreham <david_list@boreham.org>
cc:   ebxml-transport@lists.ebxml.org
Subject:  Re: tpaml spec



David,

Your points are well taken and right on the mark.  I have inserted replies
in the appended copy of your email.

Everyone, please keep the questions and comments coming.

Regards,
Marty

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


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
*************************************************************************************




David Boreham <david_list@boreham.org> on 07/18/2000 11:49:39 AM

To:   ebxml-transport@lists.ebxml.org
cc:
Subject:  Re: tpaml spec



> As promised at the Boston meeting, here is the latest tpaml
specification.
> Pleas read and comment via the list.

Some things strike me as very strange, but this could well be due to my
relative cluelessness in this field:

1. Dates in "United States format" ? There is no single US format (all
three
"orders" are in use in the US). Why not use one of the existing standard
date and time
formats ? e.g. ISO8601 (http://www.whatis.com/isodatef.htm). or RFC1123 or
ASN.1 GeneralizedTime.

MWS:  Quite right. tpaML started as an IBM Research proof of concept
prototype.
For expediency, we used dates and other parameters that we were familiar
with,
knowing full well that a standardization working group would have to do
something
about them.

2. Same point but relating to physical addresses. US format only ????
Addresses are quite hard to represent, but surely something better
than US format only can be done ? Can all address formats be
"converted" to US format ?

MWS:  Again, as a cop-out, we assumed that local software would be able to
deal
with address conversion as long as enough fields are present.

3. Same point but relating to telephone numbers. ITU E.164 is your friend.

MWS:  Ditto - for our purposes, phone numbers applicable to the US-Canada-
Caribbean were sufficient. An earlier version of the spec (prior to public
distribution included a paragraph discussing phone number formats
and suggesting that ISO standard formats might be preferred in the future.

I'm guessing that the intention is to remove these type definitions from
this spec at some point (seems strange to be defining the essence
of a telephone number in a specification for a trading prototol !), but
that for expediency they're defined in-line at present. I couldn't however
find a note to that effect in the text.

MWS:  Removing them is a good possibility.  The question has come up before
inside
IBM.  An organization using electronic TPAs is likely to have a database
containing this kind of trading-partner information so the value of having
it in the TPA is questionable. We decided to let a standardization working
group make the decision.