agenda and details for tr&p con-call jan-4-2001

[Christopher Ferris <chris.ferris@east.sun.com>]

All,

Here is the info and agenda for tomorrow's call. Same Bat-time...
same Bat-channel...

Cheers,

Chris

Con-call details:
Jan-4-2001 11 am EST/8 am PST 1.5 hours
Telephone Number (416) 406-4002
Pascode 638984

Agenda:
- report from steering committee - Rik
- resolve issues 17-22 (below) - Ian to lead
- security discussion - Maryann
- synchronous messaging discussion - Prasad/David/Dick
- (time permitting) discussion on v0.91 - David
- planning for london f2f

####

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

####
Issue 20
Title - Timeout & retry definitions
Detail - 7.12 - The Timeout and RetryInterval parameters have different
semantics as described later in this document.  However, that difference is
not made clear in this table.  Recommend RetryInterval definition be
changed to "Wait time between receiving notification of a transport error
and  sending a retry.
* Integer value specifying number of seconds.
* After any  error response is received, the Sender SHALL wait for the
specified time before  sending a retry document."  If the intended semantics
of RetryInterval  require that documents not be send more often than the
specified interval  (requiring the Sender to wait for a timeout, declaring
that status and then  beginning a wait for RetryInterval), that could be
described by changing my  words above to include a bullet such as "*
Notification of a transport error  includes detecting an expired timeout
while awaiting a response."

Proposal - Section has been reworked by Chris and David make comment
accepted or reject or see Issue 22 below for superseded proposal.
Resolution - 
Response By - January 4

####
Issue 21
Title - Error reporting
Detail - 7.13.5.4 - Either the Description element should be allowed to
repeat (providing multiple descriptions of the error in various locales) or
a  Normal message should specify the preferred locale for Error messages.
Without this, the Description content is not going to be useful with
multiple,  interoperating systems.
7.13.5.5.2 - How does this RefToMessageId relate to the one in  MessageData?
Since we aren't attempting to handle an Error response  covering multiple
messages in error (right?), change the last sentence to be  "This must be
present [and have the same value as the RefToMessageId in the  MessageData
element of the Header] if a MessageId can be identified in the  message in
error."
7.13.5.7 - According to the text of section 7.13.5.5, we've got a  meaning
for a minimum of one ErrorLocation element.  Either change  "ErrorLocation*"
to "ErrorLocation+" (requiring one or more such element) or  define the
meaning of zero ErrorLocation elements in section 7.13.5.5.  For  the second
resolution, add "If no ErrorLocation element is provided, no  information
about the specific location of the error is available.  When a  MessageId
can be determined from the message in error, the ebXMLError must  contain
one or more ErrorLocation elements." to the end of section  7.13.5.5.
7.13.5.8 - Are the two "narrative" types of information  contained in the
Description element or the ErrorCode?  Replace "that  immediately follows
the error code" with "beginning the Description element" on  line 1049.
And, replace "that follow the narrative" with "that follow the  narrative
(completing the Description)" on line 1051. Suggest that these two types of
bullets would not appear.

Proposal - David B. to investigate and lead any appropriate actions.
Resolution - 
Response By - January 4

####
Issue 22
Title - Errors and change request on schemas, DTD's and examples
Detail - Several comments were raised on the DTD's, schema and examples
which have now been superseded by new versions

Proposal -  Create a new resolution/disposition type of superseded and mark
all outstanding comments as such due to the changes made since the original
v0.21 makes tracking difficult.  Also invite the original commenters to
review the revised section once we have a new candidate version.
Resolution - 
Response By - January 4
begin:vcard 
n:Ferris;Christopher
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard