DTD Restructure Proposal

[Martin W Sachs <mwsachs@us.ibm.com>]

I have reviewed the version 0.3.1 proposal only since this is in accord
with the plan to incorporate the output of the BP Specification Metamodel.
I agree with the basic intent of the restructure, that of the entire
delivery channel being associated with a single party rather than have
multiple places where both parties appear in a single delivery channel.

Some of these comments address the broad technical issues of the proposal;
others address details on some of the tags that are not necessarily part of
the broad technical issues and in some cases may be typos in the
documentation.  I have not attempted to sort them.

Flattening of the CPP:  While I have no technical problem with the proposed
flattening, there is some understandability advantage to tags like
<DeliveryChannelSet> which merely group related lower level tags in the
same manner as intermediate directories in the hierarchical file system.  I
don't know whether these container tags are advantageous or disadvantageous
to processing of the CPP or CPA.  Is there any other disadvantage to them?

<Participants>:  We need to discuss whether the address and contact
information should be in the CPP/CPA or pointed to by them (perhaps at the
CPP owner's private site).  If we do leave them in, some fields will need
to be internationalized.

<Certificate>:  <OrgCertSource> is related to self-issued certificates.
Some people have complained that self-issued certificates are not currently
usable due to problems with public key infrastructure.  In tpaML,
<OrgCertSource> is intended only for digital envelope.

<Certificate>:  The cardinality should be 0 or more (*) since security has
cardinality 0 or 1 (?) .

<Duration>:  date and time will need to be internationalized.

<Endpoint>:  We need to discuss why the endpoint information should not be
put directly in the CPP/CPA. Since this uses CDF and HREF, an explanation
of these facilities would be helpful.

<Endpoint>:  The transport endpoint information has to be installed into
the parties' systems in order to enable them to communicate.  Just pointing
to an external document isn't sufficient as a definition.  The format of
that document has to be specified in detail just as if the information were
inside the CPP/CPA so that an installation tool can correctly parse it and
install the contents.  Similarly, a CPA composition tool has to understand
the contents of the endpoint documents to determine if they are compatible
and how to build the CPA if that information is to be incorporate into the
CPA.  (NOTE:  Compatibility may not be an issue since the endpoints
currently consist only of communication addresses.  Compatibility can be
determined by comparing the delivery channel definitions in the two CPPs.)

<Logon>:  This tag contains <UserId> and <Password>. The DTD shows that
<Logon> is required if password authentication is chosen.  In tpaML,
<Logon> is optional and there is a strong warning not to use it. The reason
is that there are security concerns when a password is included in the CPA
or CPP, even if it is intended only as a first-time password to be changed
immediately.  My personal preference is to delete <Logon> altogether (in
which case the initial passwords would be exchanged through a secure
channel, e.g. a phone call).  At least we should make <Logon> optional and
retain the warning against using it.

<CertificateAuthentication>:  This tag is in the 0.3.1 DTD but not in the
0.3.1 XML file.

<Certificate>:  In the 0.3.1 DTD, <Certificate> is under
<CertificateAuthentication>.  In the 0.3.1 XML file, it is under <Member>.
Chris' covering email says that it goes under <Member>.

<MessageEncoding>:  Missing from the 0.3.1 DTD, present in the 0.3.1 XML.

<MessageRetries>:  This seems to have been subsumed into
<ReliableMessaging>.  However the intention of <MessageRetries> in tpaML is
to support retry of application-level errors (exception responses).  We
should retain it in the CPP/CPA specification.  Placing it under
DocExchange in tpaML was purely a guess because some of these error
conditions are actually reported by DocExchange middleware.  However I
believe that it would be equally acceptable to place it directly under
<BusinessProtocol> or <Service>.

<CertificateReference>:  What is supposed to be in the #PCDATA field?

<Channel>:  In tpaML, the original intent was that there is one for the
entire TPA, which did not have to be identified in the business protocol
section, or multiple channels which could either be assigned to individual
actions or selected dynamically by the runtime.  This proposal adds a
channel ID to <Service>. This permits a separate channel ID for each
service.

    We need to agree on the meaning of ChannelId in <Service>.  Most
   likely, it defines the delivery channel to be used for the whole
   Service; if a channel ID is stated in an action (commercial transaction)
   definition, that overrides the channel ID of the whole service.

<Channel>:  We need to come to agreement on the unidirectionality or
bidirectionality of a channel.  For HTTP synchronous operations, a channel
is bidirectional.  For asynchronous actions (commercial transactions), in
the current BP team proposal, a channel is also bidirectional since
responses are not separate from the request in the same commercial
transaction.  In tpaML, a response is an action request in the other
direction, hence the channels used with tpaML actions are really
unidirectional.  If we decide that the actual delivery path is
bidirectional, we have a decision to make.  One possibility is that a
delivery channel represents the owner's receive capabilities only.  In that
case, the CPA actually has to contain pairs of delivery channels and the
channel ID in the CPA Service or Action (commercial transaction) has to
point to a matched pair of channels (i.e. a tag encompassing one delivery
channel for each party).  Alternatively, we can decide that a delivery
channel in a CPA includes both parties' receive capabilities.

<TerminateConversation>.  In tpaML, this identifies an action which ends a
conversation.  This will be replaced by the corresponding construct in the
XML generated by the BP Specification Metamodel.

<ServiceSecurity>:  In tpaML, this provides a default message security
option (yes or no) for the entire Service.  This will be replaced by the
corresponding construct in the XML generated by the BP Specification
Metamodel.

<Comment>:  In tpaML, this was intended as a place which could be used to
identify an associated paper contract without attracting lawyers' attention
:-).  We should provide some way of identifying the paper contract, perhaps
be a more meaningfully named tag.

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

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