Re: minutes 21-Dec-2000 tr&p con-call

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

Regarding Issue 19:  I would like to elaborate on my interpretation of the
stated conclusion:

"This is out of scope of the TR&P":  The RM spec needs to talk about
keeping the message in persistent storage but must be silent on when it is
removed from persistent storage since removal is at the perogative of the
higher levels. The message must remain in persistent storage at least until
the application has processed it and returned a response.  Otherwise
reliable messaging isn't reliable.

"if required it should be in the CPP/CPA":  I agree.  I think that both the
TP and BP teams need to consider this issue since it is up to the
application level to decide when it no longer needs the message.

Chris also mentioned to me that there may be an issue of a duplicate
appearing after the application has sent the response or of a duplicate
response appearing after it has been acknowledged. This might require the
message, or at least its identification information, to persist much longer
than it otherwise wood.  We need to understand the conditions under which a
duplicate an show up so late.  Could some MSH protocol need improvement to
eliminate the possibility?

Regards,
Marty


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

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



Christopher Ferris <chris.ferris@east.sun.com>@east.sun.com on 12/21/2000
12:51:13 PM

Sent by:  Chris.Ferris@east.sun.com


To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
cc:
Subject:  minutes 21-Dec-2000 tr&p con-call



Maryann Hondo
John Ibbotson
Ralph Berwanger
Chris Ferris
Philippe DeSmedt
Ian Jones
Robert Adams
Doug Bunting
David Burdett
Andrew Eisenberg
Henry Lowe
Sid Askary
Nikola Stojanovic
Marc Breissinger
Prasad Yendluri
appologies if I missed anyone

Agenda

- London f2f update (Ian)

- Discussion and voting on (Ian to lead discussion):

- Doug Bunting's proposal for handling version attribute [1]

- Ian Jones' latest list of issues from the comments db [2]

- Additional MIME headers issue raised by David Burdett [3]

- Discussion on updating the spec to v0.9 for Jan 14th
deadline.

Minutes

London f2f - 9 confirmed attendees, meeting rooms have
been arranged, projector, lunches and finger foods.
Sleepy has yet to confirm his attendance. Ian will make
lodging arrangements if notified by today.

Andrew raised issue w/r/t procedure as regards to version 0.9
which incorporates changes we have agreed to as well as
proposed changes.

Version 0.9 has both agreed to and proposed changes without
a clear distinction as to which is which.

Chris agreed to modify version 0.9 to highlight all proposed
changes (those which have not been agreed upon by the group).
Chris will post this to the list and David will post PDF
version shortly thereafter.

Sid and Prasad raised issue of turnover of 0.9x to POC
for Vancouver demonstration. The POC will be given an
early draft to review and comment before the London
face2face Jan 9, 2001. Comments and feedback will be taken
into consideration during the London face2face by the
TR&P team and released with the draft which will
be issued on Jan 15 which will serve as the basis for
the POC demo in Vancouver.

Sid raised issue of security profiles. Too much optionality
will make interoperability too difficult to achieve.
Lengthy discussion ensued... Maryann agreed to take this
issue up to a higher level. TR&P cannot make this decision
unilaterally.

On to issues to be resolved:

Issue 15
Title - RM Info
Detail - 7.9.4  - RM Info: why isn't this in routing header?

Proposal -  Move to Routing Header
Resolution - rejected without objection

Issue 16
Title - TPAInfo
Detail - Add new section containing all TPA(CPA) information
Proposal - see above
Discussion note - the version 0.9 has a section which describes
many of the CPA "parameters" upon which an MSH depends.
discussion of CPA negotiation process...
Resolution - removed TPAInfo container element,
reorganize and reword descriptions of individual elements

Issue 17
Title - Sequence number
Detail - 7.10 SequenceNumber as defined adds little or no value over the
MessageID element required in MessageData.  Recommend removing this section
and the corresponding references to SequenceNumber in later  examples, the
DTD and the schema.
If this section remains, must define the exact content of the
SequenceNumber
element when the numeric value is greater than 999.  Is the next value
"1000" or "1,000"?  Is the text for the maximum value  "999999999" or
"999,999,999" or are both allowed (and equivalent)?  Side note: Numeric
formats vary by locale and a comma is not always the thousands
If this section remains, "long time" should be defined.  At least, refer to
a TPA which makes this concrete for a specific trading relationship or
mention later text on this subject (if any).

Proposal - sequenceNumber element is defined as type int
in xsd, members are in general agreement that should be adequate
to address the typing issue. As to efficacy of SequenceNumber...
defer/table discussion/resolution of meaningfulness
of sequence number element to Jan 4th.
Resolution - vote Jan 4th, incorporate changes into spec during
Jan f2f

Issue 18
Title - URI definitions in RM
Detail - 7.10 - SenderURI, ReceiverURI and ErrorURI are not defined.  Are
they identifiers or service locations?  From later discussion in this
document, it appears that ErrorURI is a service location at which error
responses may be received.  The other two aren't discussed much.  However,
I'd recommend they be defined similarly to the PartyId elements in the
Header (i.e. the parties participating in the current leg of the journey).
That requires adding a context attribute to SenderURI and ReceiverURI and
(potentially) renaming the elements.  Alternatively, SenderURI and
ReceiverURI may somehow identify the service location used in this
particular leg (this is probably redundant information for ReceiverURI with
the transport destination and SenderURI may not exist -- not all senders
are
reachable in return).

Proposal - members to review what is written/proposed in v0.9
Resolution by - vote on Jan 4th

Issue 19
Title - Persistent storage
Detail - 7.11 - "Persistent storage" actually lasts how long?  Is the
original message deleted by the Messaging Service immediately after
receiving an acknowledgement?  In the case of an error, which is reported
to
the sending application (party), does that report also result in deletion
of
the original message from the persistent storage?
What information does the Receiver store persistently in this step?
Recommend storing the MessageID of the original message and the entire
response document.  To check for "exactly the same as the original message"
as described on line 828, may be necessary to store entire original message
or its checksum as well.

Proposal - This is out of scope of the TR&P if required it should be in the
CPP/CPA
Resolution - needs to be resolved, vote deferred until Jan 4th