Re: MTF minutes, March 28, 2008

[matthew.d.rawlings@xxxxxxxxxxxx]

I am sorry I couldn't attend, especially
as Contract messaging constraints were discussed. The key point is that
it doesn't require any particular implementation, but does state clearly
what is required. Writing as rules means no knowledge of 'current state'
is required as the rules only ever refer to the public message content.
Implementers can process 'current state' however they need to because the
rules don't use it.


Votes below:
1. one for each
2a. yes, but you must also state the
correlation function as per the Coord request of MTF
2b. yes
2c. yes



Matthew Rawlings 
+44 7917 596 827

"Brian Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx>
Sent by: mtf@xxxxxxxx

28/03/2008 17:30

Please respond to
mtf@xxxxxxxx

To	<mtf@xxxxxxxx>
cc
Subject	MTF minutes, March 28, 2008

Attendees
=========
Irina Y., ISDA
Lyteck L, ISDA
Robert S, Brookpath
Brian, GEM
Andrew J, Handcoded
Marc G, ISDA
Harry Mc., BNPP
Jason P, BGI
Henri P, DTCC
Christian N, Message Automation (late)


Regrets
=======
Matthew R., JPM


Vote
----

Due to low attendance from market participants and service providers at
the
outset of the meeting, we agreed to hold the vote on messaging options
by
email.  Please provide your vote to the list by email by COB Tuesday.
 I
will tabulate the votes and report the results next week.

Please vote on the following:

1) Number of messages for request/correct/cancel
Choices are 1, 2, or 3, as described in this week's MTF meeting invitation.
Please provide both your top choice and your second choice.  If none
of the
options receives a majority in the first round of voting, the option with
the lowest number of votes will be eliminated.  If your top choice
is
eliminated on the first round, your second choice will be used on the second
round.  If your top choice is not eliminated in the first round, it
will
still be used in the second round.

2)  Approval of the following decisions:
a) correlate messages on the same object using a unique business object
identifier (vs. correlation ID or message ID).
b) have a single processing status message with a reason code instead of
ones for each error reason.
c) combine messages so that a single business process on different types
of
objects (e.g. confirm trade, admendment, novation, etc.) is supported by
a
single message or set of messages, rather than distinct messages per object
type.

Please either vote "yes" (to all) or "no".  If
you vote "no", please also
indicate whether you vote "yes" or "no" to each subitem
(i.e. a, b, and c).



Validation of Matthew's contract message validation rules proposal
==================================================================

We discussed this at some length (in the absence of Matthew), and came
to a
number of areas of consensus or where we felt that additional clarity was
required.

1) We liked the use of the validation rule _expression_ syntax for documenting
these types of rules for processing messages.  We felt that these
types of
rules would be useful documentation for implementers.  There may be
some
advantage to this type of rule as opposed to other documentation mechanisms.
For example, they do not require the specification of a standardized state
model, which could be difficult to get agreement on.

2) We did not feel that these rules were like traditional validation rules,
because these rules require access to the current state of the processing
system (i.e. they are "dynamic" or "state-dependent").
 Other validation
rules express constraints about the content of a single message, and can
be
applied without consulting other messages.  This makes them amenable
to
being applied in a stand-alone validation application.  The rules
in
Matthew's proposal can only be applied with access to a database containing
the current processing state.

For this reason, we felt that these types of rules should be clearly
distinguished from validation rules.  They should be associated with
the
business process definitions and be termed something like "message
processing" or "request processing" rules, rather than "validation"
rules,
for clarity for implementers.

We think it would be beneficial to develop a suite of these rules, and
felt
that a quite number of the rules in Matthew's document could be useful
as a
starting point for this set.


3) We had questions about what the expected handling of different severities
would be.  For example, would a "Mandatory" rule violation
automatically
result in an immediate failure report to the sender, or could it be handled
by a repair function?  Different people on the call had different
interpretations of the likely handling of these types of rules.

4) We felt that it was essential that the context of the "collection"
of
business objects be defined very clearly for the rules to be clearly
defined.  For example, is uniqueness for business object identifiers
(e.g.
contract IDs, as listed here) required across all generators of documents,
or only within a single generator?  Should a recipient of messages
from
multiple sources validate the IDs against IDs submitted by other sources
as
well, or must they be kept distinct?  If a sender attaches multiple
IDs each
with a different scheme, shouldn't they be checked for uniqueness
including/within the scheme?

5) Can an identifier (e.g. trade identifier, message identifier) ever be
recycled, for example in case of an explicit instruction that the identifier
was incorrectly assigned?  Or, for example, could a message ID be
recycled
after, say, a month?

6) It appears that the uniqueness rules apply to all identifiers included
by
the document creator, whether or not they were actually assigned by the
document creator (the contract/header/identifier element can occur multiple
times, and the rule appears to apply to all of the occurrences).  This
means
that if a document creator attaches identifiers allocated by another party
to a contract/trade, it will be difficult or impossible to change that
association if in the future a mistake is discovered, since these
identifiers cannot be reused in another contract/trade (without causing
a
uniqueness violation).  Is it possible to distinguish to which identifier(s)
the uniqueness constraint should be applied?  (Brian suggested this
may be
more of a modeling than a validation issue).

7) Since the "identifier" element in contract has some sub-structure
(e.g.
versioned and non-versioned variants), it would be useful to have a more
precise definition of the ID matching rules. 


Upcoming
========
April 7 - Back to regular time in UK (11 AM NY, 4 PM UK):  Results
of vote,
continue discussion of object identification (other proposals), review
status.

---

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities.