Yet more issues to resolve

[ian.c.jones@bt.com]

TR&P people,

	Sorry this is late - the real world gets in the way occasionally.

The following issues may now have been overtaken by events but we need to at
least acknowledge this so that I can get the database of issue and changes
update by the New Year.


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

Proposal -  Move to Routing Header
Resolution - 
Response By - December 21

####
Issue 16
Title - TPAInfo
Detail - Add new section containing all TPA(CPA) information

Proposal - see above
Resolution - 
Response By - 

####
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 -
Resolution - 
Response By - 


####
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 -
Resolution - 
Response By - 

####
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 - 
Response By - 


Ian Jones
E-Commerce Engineer